async/await improvements

Jussi Kalliokoski jussi.kalliokoski at
Wed Nov 12 09:11:19 PST 2014

On Wed, Nov 12, 2014 at 6:17 PM, C. Scott Ananian <ecmascript at>

> On Wed, Nov 12, 2014 at 11:08 AM, Axel Rauschmayer <axel at>
> wrote:
> > Is that true, though? Couldn’t a finalizer or something similar check
> > (before a promise is garbage collected) whether all errors have been
> > handled?
> A finalizer can do this check.  This will flag some uncaught
> exceptions, but not promptly.  And as I wrote above, that's only part
> of the issue -- promises can also be kept alive for an indefinite
> period of time, but never end up either handling their exceptions or
> becoming unreachable.  This could also be an error.
> That is, liveness is one way to tell that an exception will never be
> handled, but it is only an approximation.
> And it's not necessarily an error to not handle an exception --
> `Promise.race()` is expected to have this behavior as a matter of
> course, for example.
> We've been through this discussion many times before.  Eventually
> there may be a `Promise#done`.  But the consensus was that the first
> step was to give the devtools folks time to make good UI for showing
> the dynamic "unhandled async exception" state of a program, and see
> how well that worked.
>   --scott

Actually that already works, at least in Chrome, if you execute

(function () {
  return new Promise(function (resolve, reject) {
    reject(new Error("foo"));

that shows up as an uncaught exception in the console.

> ps. some of the discussed language features threaten to release zalgo.
> but i'll not open up that can of worms.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list