Add unhandled exception notices for Deferred

[dmethvin]

Right now, if there is an exception in a .then() it is silently swallowed. I don't think we should ship 3.0.0 with that behavior.

http://jsbin.com/bodevaqive/edit?js,console

Maybe a console.warn message? We may end up yelling about rejections that might have been dealt with by a handler attached later in time.

One possible tradeoff would be to only generate the console warnings for errors that seem to be programming mistakes such as TypeError or ReferenceError. That prevents the really bad mistakes such as the example above with a typo in a function name.

For more complex cases we could recommend that people use native Promise if it's consistently available across their supported platforms, since it will be easier to debug.

[mgol]

Unhandled rejections may be handled later so going through console seems wrong to me. We could expose something like jQuery.Deferred.unhandledRejections and/or a special event people could hook to to see rejections.

If this went through a property and not events, we'd need to remove stuff from there once it's handled so we'd have to be careful about perf.

Although this:

One possible tradeoff would be to only generate the console warnings for errors that seem to be programming mistakes such as TypeError or ReferenceError.

seems like a good tradeoff to me. But maybe we could do more.

[mgol]

Also, it's worth noting what Node.js did to make working with rejections easier: https://nodejs.org/api/process.html#process_event_unhandledrejection

tl;dr: a unhandlerRejection event. We could do both that and a console.warn for TypeError/ReferenceError.

[timmywil]

I'm not a fan of console messages from a production library. What about removing the default unhandled rejection handler – which would just rethrow – if another handler is attached?

[gibson042]

I don't have time to address this today, but we can talk about it at the next meeting. I'm opposed to the core library having an opinion, and still maintain that it's a plugin problem for now. I'm happy to write it... have we documented current best practices?

[timmywil]

@gibson042 There's a note about it in the blog post, but I don't think we've added anything to api.jquery.com about it. Is the deferred.then page the best place for that?

[timmywil]

Also, I agree. Supporting Promises/A+ is a mixed bag for this reason. I'm inclined to leave this up to the user, but warn strongly against allowing phantom errors.

[dmethvin]

Having a default that swallows errors is really bad though, especially compared to the current behavior that gives immediate feedback about programming errors.

[timmywil]

It is bad, but there's an argument to be made that it comes with the territory. Either way, we'll probably be more equipped to make this decision if we have code to review. My backlog is clear. I could mock something up.

[markelog]

Ref tc39/ecma262#76