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.

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.

Replying to [comment:2 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.

#14218 is a duplicate of this ticket.