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 <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 prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~----------~----~----~----~------~----~------~--~---