jQuery.Callbacks left in inconsistent state after exception

[seb]

This problem still exists in 1.10.1 and in the current git.

Please don't close it as a duplicate!

See ​http://jsfiddle.net/GaL2D/ for a demonstration.

This line should probably be wrapped in a try/catch-block:

​https://github.com/jquery/jquery/blob/master/src/callbacks.js#L68

[dmethvin]

Duplicate of #11193.
But the ticket that is the duplicate, #11193, explains why it is that way. If you expect your code to throw exceptions, try/catch inside it.

[anonymous]

Yes, it's a good idea to catch the exceptions yourself.

But what about 3rd-party code that you can't control?

If such code uses $.Callbacks and throws an exception, the whole Callback-infrastructure will cease to stop working, which IMHO isn't a very good design-decision.

[jaubourg]

Replying to anonymous:

Yes, it's a good idea to catch the exceptions yourself.

But what about 3rd-party code that you can't control?

try {
  callThirdPartyCode();
} catch( e ) {
  // can control (or rather ignore, right?) at will
}

If such code uses $.Callbacks and throws an exception, the whole Callback-infrastructure will cease to stop working, which IMHO isn't a very good design-decision.

You have an unchecked exception that may be indicative of an instability in your application. Is it reasonable to just ignore it and keep going ? Or would you rather know about it ASAP and have the program stop doing whatever it was doing ? Of course, it depends.

For instance, what about a runtime exception that would only happen in production ? What about an exception in your own code (not third-party) ? What about a syntax error when debugging/maintaining code ? How long before you spot the problem if the Callbacks instance keeps working as if nothing happened ? Should those be just reported in the console and then ignored ?

More importantly, if ignoring exceptions all the time is proper design, then I suppose you use try/finally whenever you call a function synchronously (hint: nobody does, of course) ? If you don't, what happens to the rest of your program infrastructure when an exception is thrown (hint: exactly what happens here) ?

The original reason why we "break" the Callbacks internal state was because older IE7 (iirc) would choke on a try/finally without a catch and adding a catch/rethrow removed important debugging info (filename and line number). Believe it or not, I used to think try/finally what a good idea. In retrospect, that would have been a gigantic pain for all the reasons exposed above.

It's easy enough to try/finally around the problem when and only when needed.

[jaubourg]

#14218 is a duplicate of this ticket.