#14201 closed bug (duplicate)
jQuery.Callbacks left in inconsistent state after exception
Reported by: | seb | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | 1.10.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
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
Change History (4)
comment:1 Changed 10 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:2 follow-up: 3 Changed 10 years ago by
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.
comment:3 Changed 10 years ago by
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.
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.