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 15:25:50 -0400
Message-ID: <541348BE.6050808@mit.edu>
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

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