> No harm in
> asking!https://prototype.lighthouseapp.com/projects/8886-prototype/overview
>
Thank you for the reference.
I found this interesting ticket on the subject:
https://prototype.lighthouseapp.com/projects/8886/tickets/634-no-exception-on-error-in-oncreate-method-of-ajaxrequest
Tobie L
Hi,
> I really think the core team at least should consider updating
> the docs
No harm in asking!
https://prototype.lighthouseapp.com/projects/8886-prototype/overview
> It will spare a significant portion of new prototype users from being
> confused about this.
I very much doubt that it's any
Thank you for your reply.
On Jun 14, 10:22 am, "T.J. Crowder" wrote:
>
> I don't speak for the Core team, but I don't see it happening if none
> of them have jumped into this thread so far.
>
Yeah, you are probably right. If they feel things are optimal as they
are, I really think the core team
Hi,
> when the function
> provided via onComplete is executed there will be no sub routines in
> the call stack
Right (well, not very many). But if you look again a Glenn's
suggestion, he's saying that not having an onException handler in your
Ajax options is analogous to not having a try..catc
Any news on this? I myself was confused with the way Prototype seems
to be swallowing exceptions without giving the developer a clue about
it.
As Glenn, I really feel that exceptions thrown from an ajax request
should somehow be propagated upwards if no explicit onException
(analogous to a catch
On Fri, May 15, 2009 at 4:47 AM, T.J. Crowder wrote:
> I don't see any point in continuing this. You feel quite strongly
> about this and I'm unlikely to change your mind. I feel less strongly
> about it, but you're not likely to change my mind either -- not that
> it matters either way, as nei
Hi,
> Please explain why it should not propagate exceptions normally...
I don't see any point in continuing this. You feel quite strongly
about this and I'm unlikely to change your mind. I feel less strongly
about it, but you're not likely to change my mind either -- not that
it matters either
On Thu, May 14, 2009 at 8:17 PM, T.J. Crowder wrote:
>> Sure, after figuring out why exceptions are disappearing, and then
>> figuring out how to get around that all-encompassing exception block
>> surrounding the responder. It's a lot of digging to get reasonable
>> default behavior.
>
> Or, yo
> Sure, after figuring out why exceptions are disappearing, and then
> figuring out how to get around that all-encompassing exception block
> surrounding the responder. It's a lot of digging to get reasonable
> default behavior.
Or, you know, read the documentation. ;-)
No, seriously, we'll hav
On Thu, May 14, 2009 at 3:24 AM, T.J. Crowder wrote:
> I don't think they would, but more to the point, "raised normally"
> *where*? In the normal case (asynchronous requests), the code that
> initiated the request has long since completed. So unless you mean
> raising exceptions to the browser
Hi,
> swallowed. The behavior I think most people would expect is that if
> they're not using any onException handlers, exceptions should be
> raised normally, not silently discarded.
I don't think they would, but more to the point, "raised normally"
*where*? In the normal case (asynchronous r
11 matches
Mail list logo
