- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 12 Sep 2014 14:50:17 -0400
- 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 improvement. > 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? -Boris 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