I don't know much about the code in question, but I believe those
catch blocks are in place to intercept thrown exceptions that are
extraneous (i.e., can occur sporadically without changing the result
of the code or have no bearing on the result).  I can't be sure,
though, so let's take them one by one:

(1) Try.these.  I think the empty catch block is justified here. The
function is designed to envelop an arbitrary number of functions that
may or may not throw exceptions. So the developer is saying, "I know
this may throw an exception, but I don't care about the details
thereof: just let me know if this works or not."

(2) Ajax.Responders.dispatch.  It looks like the catch block is in
place to ensure that every callback gets called.  Otherwise a previous
callback registered by someone else could throw an error and prevent
your callback from firing. Does anyone else in Core know more about

(3) Event.stopObserving. The empty catch block is encountered in IE
only.  My guess is that detachEvent throws an exception if the
specified observer doesn't exist on the element -- which
addEventListener does not, so Event.stopObserving normalizes the
behavior.  But this is just a theory.

Question for all: in each of these cases, if it's agreed that we need
to suppress the exception, can we re-throw it at a later time?  Or
find some other way to indicate that an exception has occurred?


On Apr 1, 3:33 pm, "Ben Weaver" <[EMAIL PROTECTED]> wrote:
> Hello,
> I've recently started using prototype 1.5 or a large project.  It's
> been a great experience so far.
> As I've been developing, I noticed that many times exceptions raised
> by errors in my code (such as, say, trying to use some property of a
> null object, etc.) would not show up in my javascript console (I am
> using Firebug).  More troubling were exceptions that the code
> explicitly threw that also mysteriously vanished.
> I just worked around this for a while by interspersing console.log
> statements at key places in the code I was working on, but I
> eventually became curious about why errors would sometimes appear and
> other times not.
> I looked more closely at prototype.js and found 3 empty catch blocks
> (Try.these, Ajax.Responders.dispatch, Event.stopObserving).  The one
> that was affecting me was in dispatch().  I found that
> Ajax.Request.dispatchException() invokes Responders.dispatch for
> onException callbacks, so I added
>    Ajax.Responders.register({ onException: function(req, e) { throw
> e; } });
> to my code, but the empty catch block in Ajax.Responders.dispatch()
> catches all exceptions raised by responders and discards them.  I
> tried editing dispatch() to always throw errors that it catches;
> afterwards exceptions successfully appear in my console.
> I'm using this workaround now:
>   Ajax.Responders.register({ onException: function(req, e)
> { console.log(e); } });
> and it works well for me.
> I wanted to relate this experience to you because I feel that the
> empty catch block in dispatch() (I can't comment on the others),
> violates the "principle of least surprise".  I expected (and perhaps I
> shouldn't have?) uncaught exceptions to show up in my console and stop
> execution since this is the default behavior.  Perhaps there are
> strong reasons for choosing to use an empty catch block in dispatch(),
> but if there are not I would suggest allowing exceptions raised by
> responders to be thrown, or at least to do something like this
> (admittedly ugly) compromise:
> dispatch: function(callback, request, transport, json) {
>     var dispatched = false, exception = null;
>     this.each(function(responder) {
>       if (typeof responder[callback] == 'function') {
>         try {
>           responder[callback].apply(responder, [request, transport,
> json]);
>           dispatched = true;
>         } catch (e) { exception = e; }
>       }
>     });
>     if (!dispatched && exception && (callback == 'onException'))
> { throw exception; }
>   }
> Thanks for developing such a useful library.
> Best wishes,
> -Ben

You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to