On 9/12/14, 3:19 PM, Domenic Denicola wrote:
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?
No.
That's not compatible with "the events always get fired", afaict....
Are we talking about different situations here somehow?
This presumably implies keeping the promise alive and not allowing the garbage
collector to collect it until that task executes, right?
Interesting. This seems OK since it would only be until the queued task
executes, which should be very soon.
There's no obvious guarantee of that, especially in workers.
But if this complicates implementations undesirably, we could fall back to
integer IDs or something. The only important thing IMO is being able to match
up `error` and `rejectionhandled` occurrences, and to me the promise itself was
a good key.
The promise itself can't be shipped out of the worker scope to the
onerror on the Worker itself; that's why I was asking what we want to do
with workers. If we want a unique key thing there we need some
non-object (or at least structured clonable) key.
-Boris
