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
Errors in my code, when I havn't installed any error handler
explicitly, should be returned to the browser, to be displayed in the
usual error windows. If I want some other behavior, I'll install an
error handler (whether a try/catch block or, for Ajax.Request, an
onException handler). Discarding errors by default is very strange.
The exception should minimally be re-thrown if no onException
handlers, local or global, exist. Attached patch (not heavily tested)
shows what I mean.
> to be a fairly useful paradigm. (try = request, catch = onException,
> finally = onComplete) Maybe there could be an argument for
Errors in onComplete are also sent to onException, so I think this
mapping is a little off.
> 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-
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.
--
Glenn Maynard
The documentation explains how to set exception handlers within AJAX.
It does not explain that if you don't set one, exceptions will be
silently ignored; to figure out why my callbacks were silently doing
nothing I had to trace the source. Nor does it explain how to force
exceptions to be propagated normally; delaying the exception in a
defer() is hardly obvious.
> No, seriously, we'll have to agree to disagree on this. I'm just one
> counterpoint to your statement that "most people" would expect
> something else. I wouldn't. I expected, and quickly found when I
> started using Prototype's Ajax stuff, exactly what's there. I find
> the default behavior quite reasonable.
You find the default behavior of silently ignoring all exceptions
reasonable? Seriously?
Please explain why it should not propagate exceptions normally when no
error handlers are set. You havn't given any rational explanation.
If you're using exception callbacks, then this has zero impact on you.
--
Glenn Maynard
If you're not going to explain your opinion at all, then no, there's
no point in continuing this with you. You havn't offered a single
reason for why the errors should not be raised if no exception
handlers are set. Don't just assert your disagreement and then refuse
to explain it.
--
Glenn Maynard