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 requests), the code that
initiated the request has long since completed. So unless you mean
raising exceptions to the browser (which doesn't seem like a good
idea, and can result in your script being terminated completely), I
don't see where it would get raised. And there's no standard for a
global exception catcher, is there? Some browsers have them, I think,
but I don't know of a standard for one. So even if Prototype raised
the exception globally, how would you handle it?
No, having a callback for exceptions makes sense to me. As with a
standard try/catch/finally block, your exception handling logic is
near (but not interspersed with) your mainline logic, which has proven
to be a fairly useful paradigm. (try = request, catch = onException,
finally = onComplete) Maybe there could be an argument for
synchronous requests to raise the exception out of the Ajax.Request
constructor, but I think it's trumped by having a uniform way of
handling exceptions for all Ajax requests (rather than different
mechanisms depending on whether you're doing a synchronous or async
request).
If you want to semi-globally handle all exceptions in Ajax requests,
as you show you can do it with a responder. If you want to semi-
globally handle all exceptions only in your own Ajax requests (and
not, say, Autocompleter's), a factory function readily handles setting
that up on each request.
function ajaxRequest(url, options) {
options = options || {};
options.onException = options.onException || yourGlobalHandler;
return new Ajax.Request(url, options);
}
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On May 14, 3:40 am, Glenn Maynard <[email protected]> wrote:
> Exceptions inside AJAX handlers are sent to onException and then
> 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. That's the behavior I
> want--for errors to always go to the error console, like all other
> errors. (I can see the underlying reason for this behavior--so
> callbacks are guaranteed to be called, even if one of them
> misbehaves.)
>
> I can work around this with a responder:
>
> Ajax.Responders.register({
> onException: function(request, exception) {
> (function() { throw exception; }).defer();
> }
>
> });
>
> The defer() is necessary to break out of Ajax.Responders.dispatch's
> exception handler, which silently eats everything. This also has the
> nice property that if multiple callbacks throw errors, the callback
> chain isn't broken, but all of the errors are still shown. It's also
> not dependant on responder order; if it's registered first, later
> responders still run.
>
> I'm not sure if throwing an exception outside of the context it was
> originally thrown will confuse JS debuggers. (I don't use one; they
> all destabilize FF badly for me.)
>
> It would be nice to have this behavior by default. I suspect most
> people who use Prototype AJAX have been bitten by this, and this
> workaround is a bit obscure for people to have to discover on their
> own.
>
> --
> Glenn Maynard
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
