> 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

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 <gl...@zewt.org> 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 prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to