Should not be catching and then re-throwing "ready" exceptions

Description

Catching and then re-throwing exceptions has two issues:

1. Makes finding and correcting mistakes much harder. Need a live stack trace and paused code, not a later report logged by a timeout (which isn’t of much use for debugging). Most app code exists (or at least starts) in “ready” callbacks, so this is absolutely crucial.

2. It allows the app to continue when we know it is in an unknown state. That’s bad news in development and in production. An exception should stop the show immediately.

Already know the counter-argument and the answer is simply: the ready method is not a “polyfill”. We don’t have to mimic browsers to a T here (and doing so creates the above issues).

The re-throw is a recent change, but it does very little to address the issues that always existing in catching exceptions in “ready” callbacks.

Will correct the related code in my fork shortly.

Link to test case

There is no test case for this. It’s simply an undesirable behavior that should be corrected.

[dmethvin]

Once one “ready” callback goes, it’s time to halt.

Gack, no! We don’t want the ready handler be a single point of failure for the entire page. We were there in previous versions and it caused a lot of trouble. Note also that the native DOMContentLoaded events do not behave this way, they continue to run additional handlers even if previous ones throw errors. We are aligning our behavior with that.

What possible reason is there to continue once the code has gone off the expected path?

The reason is that on a modern web page, “the code” often isn’t written by one person. It’s a combination of plugins or code fragments that work independently on different parts of the page and have different ready handlers. In the face of hostile code such as ad blockers and browser add-ons there is a good chance that something will break on some combination of browser, platform, and add-ons. I do not want my charitable donation form to break just because of a rare failure in a tooltip plugin that is not essential to the functionality of the page.

[david-mark]

There is a lot in JavaScript that happens asynchronously and, as a rule, an uncaught error in async code doesn’t stop code execution outside of the current async context. This doesn’t have a lot to do with jQuery but with the language itself.

That’s completely false when debugging as ECMAScript is single-threaded. As for production, it’s still silly to wrap all of your callbacks in try-catch. Can’t imagine calling the “ready” callbacks asynchronously either, but that’s another story. Can call them synchronously or asynchronously; not sure how we were managing to call some synchronously and some not. Perhaps you are referring to what happens inside the callbacks, but I digress.

I’ve already answered that question. We want the callback to be always invoked asynchronously instead of sometimes synchronously and sometimes not. We don’t plan to change that back.

None of that has anything to do with catching exceptions. In fact it’s even more important to catch them during asynchronous operations where the cause will likely be harder to track down later. These are the ones that can be sporadic as well. 😉

Thanks for your suggestion but since it seems that this issue is about making the ready back > sometimes synchronous and we don’t plan to do it, I’m going to close it.

I’m afraid you have completely missed the point here. 😦