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...
