W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] An API for unhandled promise rejections

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Fri, 12 Sep 2014 14:50:17 -0400
Message-ID: <54134069.5090807@mit.edu>
To: whatwg@lists.whatwg.org
On 9/12/14, 2:34 PM, Domenic Denicola wrote:

Thank you for writing this up.  This is definitely an area that needs 

> As usual, if one or both of these events is missing listeners, nothing will happen.

I'm not sure that's "usual".

Specifically, an observable case that's worth considering:  if there is 
no listener for "error" but there is a listener for "rejectionhandled", 
does the latter get called?  If there is no listener for either when the 
promise would normally fire error, but then a listener for 
"rejectionhandled" gets added before a .catch() call on the promise, 
does the listener get called?

It seems to me like from a spec point of view if this sort of thing is 
done the events should fire unconditionally instead of depending on 
whether listeners exist, like other events in the platform.  If there 
really are no listeners, such that UA shenanigans are not observable, 
UAs are free to perform those shenanigans, whatever they are.

> We would add a new event to the global, named `rejectionhandled`, along with a `RejectionHandledEvent` class that contains only a `promise` member.

Worker globals too, right?

What is the resulting interaction with onerror on the worker object 
itself?  Would we grow an onrejectionhandled attribute on AbstractWorker 
as well?

> * When a promise is rejected, if it has no handlers, we would queue a task to potentially-fire-an-error.

This presumably implies keeping the promise alive and not allowing the 
garbage collector to collect it until that task executes, right?


P.S.  I'm torn on whether to reuse existing onerror mechanisms for this 
or not...
Received on Friday, 12 September 2014 18:50:42 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC