- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 12 Sep 2014 15:25:50 -0400
- To: Domenic Denicola <domenic@domenicdenicola.com>, "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
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
Received on Friday, 12 September 2014 19:26:13 UTC