From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Boris Zbarsky
>> As usual, if one or both of these events is missing listeners, nothing will >> happen. > > I'm not sure that's "usual". I think I misspoke here. The events will still be fired! Anything else would be insanity. I just meant that from a developer perspective, nothing important would occur. > 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? Yes. > 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. > 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. Definitely agreed. > Worker globals too, right? Sounds good to me. > What is the resulting interaction with onerror on the worker object itself? > Would we grow an onrejectionhandled attribute on AbstractWorker as well? Yeah, that would make sense to me. > 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. 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. (I might be missing some use cases where the promise comes in handy, but off the top of my head I can't think of one.)
