We still need a test case, preferably on jsbin.com or jsfiddle.net, that demonstrates the problem you are reporting. Your prior ticket was closed because it violated our code of conduct, not because of any technical merits.

The test case is using tracebacks and source-maps. It seemed fairly obvious to me that people do that all the time sufficiently enough that no further explanation is required. Apparently I'm wrong, so there:

• Live test case: http://codeflow.org/issues/jQuery/tracebacks/
• Archive of the test case attached tracebacks.zip

Screenshot with overall comparison:

Functional examination of browser built in traceback.

Functional failing of jQuery traceback

That's pretty much what we needed, thanks. Adding this line right below the jQuery script tag:

<script>jQuery.Deferred.exceptionHook = function(e){ throw e; };</script>

Gives this result

Of course this breaks Promise/A+ compatibility but I understand that it can be really handy for debugging, especially for all that legacy Coffeescript. If you threw a custom error subclass rather than Error you could narrow this down by adding the subclass to the regex in the original but I'll leave that as an exercise.

There's lots of trans/compilers that make use of source maps besides coffeescript, such as Dart, Typescript, Emscripten, Google closure compiler, etc. There's also lots of tools that concat/uglify/beautify/compress/etc. JS that use source-maps, the tools that compile jQuery itself among them.

Besides missing source-map support is but one of the many failings of the broken traceback that jQuery causes.

Can you let me know if this fixes your issue in situ? If so I'll close this ticket and we can look at some wording for the upgrade guide.

It's pretty obvious this is an issue, that's not fixed. Breaking tracebacks and source-maps as an out of the box behavior not acceptable for any library, let alone one as widely used as yours.

I'm not sure why you are saying that is not fixed. Adding that one line gives a traceback that is very close to the one you had before. If we shipped it with that one line would you consider it fixed for your use case?

I would consider it acceptable if jQuery was shipped with that fix.

@pyalot It has already been clearly stated that making such a change inside jQuery is not compatible with standards. We will not fight against the standards just because you're being pushy. Please refrain from restating your same opinion over and over as it is not helpful.

Please acknowledge whether that one line of user code that @dmethvin provided solves your problem of tracing the error through code that uses source maps.

It does not solve the problem that jQuery breaks tracebacks and source-maps. I refuse to acknowledge that this would be any kind of "solution". If you can't ship that with your library, you will have to find other ways to fix the issue, including talking to the "standards body" in question, and talking to browser vendors to provide you the necessary abilities to fix it.

I advise you not to close this ticket again, it is not fixed, and you'd only prove my point that you don't care about getting it right.

I think we all agree that respecting sourcemaps in the traceback is ideal. The problem here is that the solution is not compatible with the spec to which we must be compliant. If we have no suitable solution, we have to close the ticket because there's nothing more we can do. That said, Dave maintains a plugin that helps with debugging jQuery Deferreds (which is used in jQuery.fn.ready). If he knows that the solution he suggested works for you, he may be able to use that in the plugin. You could then use the plugin when debugging and we both follow standards and provide you with the best possible workaround.

Or, you can overwrite the default console.warn and throw instead in your own code with one line...

jQuery.Deferred.exceptionHook = function(error) { throw error };

http://jsbin.com/minegi/1/edit?js,output

If you think of a solution that is compatible with Promises/A+, please comment here and we can reopen the ticket.

The thing is that the two cases you provided are not equivalent. Adding an event listener for the DOMContentLoaded event is inherently different from adding a callback for the fulfillment of a promise. If you really want DOMContentLoaded, then you can still use jQuery to listen to that event. But if you want the extra sugar of a promise that will still invoke its callbacks even if they're added after the DOM is ready, then you're going to get the standard Promise behavior.

There are clear avenues of investigation open to you such as talking to the standards committee that specifies promises, and talking to browser vendors about APIs that help you to fix this issue. You closed the ticket nevertheless.

Closing this ticket is a mistake that proves my point about a lack of commitment to get things right. It's to the detriment of everybody who writes JS for this lackluster attitude to persevere. Setting an example in mediocrity to follow for many others. Hurting the ecosystems foundations upon which JS'es success is built. I cannot subscribe nor condone such a process and I find it abhorrent and repulsive.

@pyalot We actually fought hard on this issue, but the battle is over. We lost. All we can do now is follow the spec because despite your fervor, you are in the minority.

Then talk to browser vendors, as I've mentioned, multiple times, for the introduction of the necessary APIs that lets you fix tracebacks.

Technical issues are not a democracy, and being in the minority does not matter. The issue is clear, the merits of solving it are too. The evidence is clear as day for everybody to see. Nobody can honestly argue that I'm wrong in pointing out this issue, and its detrimental impacts. If something can be solved, it should be solved, and it clearly can be solved.

I reported it to Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=622227. Can we escalate it somehow? @paulirish?

I'm talking to Kenneth Russell about this issue and a more fundamental solution. I have done some tests around in which circumstances Chrome does do the source-map translation (and URL shortening), but the prepending of jQuery's own error string to the front of the traceback breaks Chrome traceback parser. In any case, other browsers don't implement that, and it's still not a nice error display.

And even if that was satisfactory, the reordering of execution by the promises semantic that breaks traditional exception handling wouldn't be fixed and tracebacks would still be rather useless, and it'd be nice if structured traceback handling was offered so that things like the promises debugger could be shipped out of the box and work as expected with built-in traceback displays.

I'd rather think that questions of proper tooling should've been addressed in promises, before they're plastered all over every which API and library and apparently nobody has any clue how to debug the mess that it's ridden everybody into.

the prepending of jQuery's own error string to the front of the traceback breaks Chrome traceback parser.

Can you propose a change that will make it better? We could do two separate statements if that helps.

Can you propose a change that will make it better?

Yes, don't modify the string you get from error.stack in any way. Any modification to it will break Chromes traceback parser.

I think it's futile to guess at what the error parser of chrome does, because its rules aren't standardized, and in any case, other browsers don't do it. And the error display isn't user friendly, because it's not styled like a normal error, and it can't be collapsed.

You can see the code, it's not modifying error.stack. Rethrowing the error gets Chrome to show the stack formatted, but throwing at that point violates Promise/A+ so we can't do that as the normal action.

This is the bit that breaks chromes traceback parser:

"jQuery.Deferred exception: " +

This is the bit that breaks chromes traceback parser:

This is adding to error.message, not error.stack.

At the issue https://bugs.chromium.org/p/chromium/issues/detail?id=622227#c3 I got a response that it's enough to console.warn the error and the stack will be available with properly applied source maps. @dmethvin: did you try it?

Chromes generates its own error string (error.stack) and when you pass that to console.error/warn/log it re-parses its own error (and applies the appropriate source-map translation). This is undocumented behavior that was introduced in response to a ticket I wrote about that. The parsing chickens out if the format does not exactly conform to chromes undocumented error.stack format.

It's inappropriate to send errors to console.error/warn/log because that produces a bad error display that provides a worse UX (even if it works as expected), than the built-in error display (see screenshots).

It's also inappropriate to receive errors in an unstructured, undocumented format that varies from browser to browser.

It's inappropriate for browsers to re-parse their own errors they've just produced themselves, for exactly the above reasons.

The proper response to this whole thing would be to:

1. Introduce a standard stack format
2. Provide that standard stack format (lazily) on an error if asked to do so (like error.traceback getter), that does whatever the browser finds necessary to obtain that structured format.
3. Provide a console API to accept a standard stack format, such as console.traceback, which formats the standard stack traceback according to how the browser usually formats errors.

Javascript is among the only popular languages that does not have any kind of structured traceback handling. The introduction of error.stack was poorly conceived, the failure to standardize it was ill advised, the integration of promises into browsers was rushed and ill advised in face of a complete lack of proper error tooling, all these mistakes should not be compounded with the mistake of not fixing it now.

Let's revisit this for 4.0.0. PR: #5192.