As your example points out, being unhandled is a changing state. All rejections start out unhandled, but can become handled either immediately or in a later turn. The only time in which you can be sure a rejection is unhandled is when the promise is garbage collected, which may never happen (but usually does).

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of evan at evan-borden.com
Sent: Sunday, September 8, 2013 20:25
To: To=; es-discuss at mozilla.org
Subject: Subject=Re: Re: Promises: final steps


Tasks in C# throw the recorded exception when the Task is finalized by the GC if it hasn't been handled by user code, though I don't know if something similar could be supported for ES7 Promises nor whether or not that makes sense for ES7 promises either.

This is an interesting avenue. The problem is the chain-ability and value like nature of promises. It is difficult to truly determine that the error has not been handled. The error may be handled later down the chain or in a separate context. When is the decision made that the error has not been handled? Is the error determined not handled on garbage collection? Is there a ttl on error handling? This is a curious case, but if feasible would be the most elegant option.

rejectedPromise = promise.then(func)
    .then(func) //Error swallowed
    .then(func);

setTimeout(function () {
    rejectedPromise.then(func, errorHandler); //Finally handle it
}, 20000);

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130909/aa639e72/attachment.html>

As your example points out, being unhandled is a changing state. All rejections start out unhandled, but can become handled either immediately or in a later turn. The only time in which you can be sure a rejection is unhandled is when the promise is garbage collected, which may never happen (but usually does).