Feature Request: Add Unhandled Rejection Options to the Web Polyfill

[jtfairbank]

Hi guys, kinda a noob in the whole Promise architecture scene. I've been using them for about a year now with great success, but beyond reading promisejs.org a bunch I haven't really delved into the framework code or beyond the basic theory.

However I really liked the idea of the Unhandled Rejection options as a way to customize how you want promises to work.

1. Finish All Promises with Done (Current Method)

P().then(...).done();

The nice thing is that this is explicit- I am done with a promise after this point. The problem is that it requires constant diligence to place the done, and can often be confusing about where to put it:

• Every function that calls a function that returns a promise is responsible for adding a .done() to it, or passing it on to others that must then add their own .done(). This is quite problematic if your call stack returns a promise 2 or 3 times, since it is not easy to see that on the surface in javascript without explicit comments or static analysis tools (are there even any for this?).
• .then() chains can split into trees by assigning various points of a .then() chain to variables and .then()-ing off of those (although I'd say that is a code smell).
• A single failure to end a promise in .done() means that any errors in those codepaths are squashed.
• There is no distinction between rejecting a promise, throwing an error that should result in a rejection, and throwing an error that is truly an exception and should crash that code path. To be fair, I think hitting both of the last two would be very hard or even impossible.

Currently, when an error is thrown in a promise and not handled by the .then() chain, I get an error in the console: Uncaught (in promise) Error. However it does not trigger window.onerror so my unexpected exception handling code does not work.

The first few comments here describe some of the problems more eloquently: promises-aplus/unhandled-rejections-spec#5.

2. Same Thing as #1, but "Uncaught (in promise) Errors" Act Like Normal Errors

It makes sense to me that if the promise library is going to throw an error, it should act like any synchronous code or callback that throws and error and trigger the winodw.onerror event.

3. The Full Suite of Unhandled Rejections Options

This would be ideal as it is the most customizable. Perhaps it can be accessible via a property on the Promise object? Or via another object that Promise interacts with?

Seems like the issues in promises-aplus/unhandled-rejections-spec have some good ideas:

• Environment Hooks
• Library Hooks
• Fail Fast Always

4. Better Tooling

If the best way to go is via .done(), then perhaps we can have better tooling to help discover which code paths don't call done?

Are there any existing static analysis tools / jshint extensions that are compatible with this library?

Is there an option to turn on Lazy Promises?

Closing Thoughts

This feature request might be harder to do since some browsers seem to implement Promise's natively (ie Chrome). Maybe it'd be possible to wrap native implementations and just add this code in the wrappers?

Let me know how I can help!