Support a "capping required" mode of operation; or allow reporting unheard rejections.

[kriskowal]

Support a "capping required" mode of operation; or allow reporting unheard rejections.

[kriskowal]

This has been on the back of my mind for a while. Tracking resolved/unresolved promises is also good for what you did earlier for waterfall analysis. We definitely need something, perhaps the ability to create Q sandbox instances that can create a report of the outstanding promise graph.

var {Q, pool} = Q.create({debug: false});
var promise = Q.defer('annotation').promise;
assert.deepEqual(
   pool,
   [{promise: promise, annotation: 'annotation'}],
   'promise pool contents'
);
promise.resolve();
assert.equal(0, pool.length);

I'll be away for a week, so I will probably not be able to have a lively discussion for a while. That said, I do want to have more dialog with friends and supporters. We need to be a more tightly knit group and I need to be more conscious of how Q is being used in the wild.

[asutherland]

Sandboxes and support for annotations would be excellent, although I should be clear that my biggest concern in this issue is that use of Q can lead to quietly eaten exceptions. The Mozilla platform (at least when dealing with the non-browser XPCOM stuff) loves to eat exceptions, and I don't want to go back to that, so it would be great to make sure that rejections (that are exceptions, at least) are always re-thrown if not explicitly handled by the user.

In any event, Q is working fantastically for me, especially with a minor hack patch to re-throw errors. Thanks again for all the great work on Q, have a good week away/off, and let me know if there's a mailing list you would like to use to discuss such issues.

(The XPCOM issue in a nutshell, if you are interested, is a 1) fundamental impedance mismatch between C++ and (transparently-exposed) JS and 2) the use of integer success/error codes in the C++ code. The XPConnect code allows JS code to obey the C++-style IDL interfaces, but has a hard call to make when an exception propagates upward, because it is able to translate the exception to an integer failure code, which may or may not be desired... it can't tell and can only either report every exception it sees or just translate them to integers. Unfortunately, that sucks quite extensively for developers. Q is in the much more advantageous position of being able to tell that there is no one explicitly handling/translating an error, and thus that it can/should be reported.)

[johnjbarton]

I believe issue 30, #30, is a example of the problem being discussed here.

[jrburke]

This came up in volo too, and recently saw a link to domains in node which sounds similar to the pool approach that @kriskowal mentioned. I do not have anything helpful to add, just mentioning data points.

[domenic]

WinJS has a similar solution to Q, where .done(f, r) is equivalent to Q's .then(f, r).end():

• http://msdn.microsoft.com/en-us/library/windows/apps/hh700337.aspx
• http://msdn.microsoft.com/en-us/library/windows/apps/hh700334.aspx
• http://blogs.msdn.com/b/microsoft_press/archive/2012/06/04/free-ebook-programming-windows-8-apps-with-html-css-and-javascript-first-preview.aspx page 78

The latter has a particularly poignant quote:

In practical terms, this means that if you end a chain of promises with a then and not done, all exceptions in that chain will get swallowed and you’ll never know there was a problem! This can place an app in an indeterminate state and cause much larger problems later on. So, unless you’re going to pass the last promise in a chain to another piece of code that will itself call done, always use done at the end of a chain even for a single async operation.

In practice, we've adapted to the status quo, and adopt the simple rule to always either (a) return the promise; or (b) cap with .end(). We enforce this even for promises that have error handlers, just in case the error handler itself throws, and also to make the rule simple and easy to follow without thinking.

[kriskowal]

end() is very much a stopgap, which is why I favor it over .done(). There are two cases where we will find ourselves editing the end of promise chains. The first is when you have to add another step. After a done, you have to walk back and forth to switch the previous done to then and add a done. With end, you just chain a new then between the previous and the end. The latter case, when good visualization tools for the state of a promise graph are available, it is my hope that .end() calls will become vestigial and trivial to remove.

However, I still think there would be value in introducing promise domains (pools as it were, but I think domains is going to catch on).

[domenic]

See also promises-aplus/unhandled-rejections-spec#4

[kriskowal]

It’s time to put this issue to bed. There are three directions being pursued.

1. Domains exist. This mostly obviates the need for pools, which would probably not be ergonomic in the long run.
2. Discussion about end vs done has run its course.
3. Options are being explored for debugger extensions that surface transient unhandled rejected and pending promises, either through a separate window or logging and unlogging.

Thanks, @asutherland. This is the longest lasting, most relevant issue we have.