From: Boris Zbarsky [mailto:bzbar...@mit.edu]
>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?
Probably. Some code would help :). I envision the scenario you're describing as:
```js
var p = Promise.reject(new Error("boo"));
setTimeout(() => {
window.onrejectionhandled = () => console.log("got here");
}, 100);
setTimeout(() => {
p.catch(() => {});
}, 200);
```
In this case the event would be fired, but no listener would be present at that
time, so "got here" would not be logged. What scenario were you envisioning?
> 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.
Oh, hmm, I didn't realize you could listen to worker errors via
`workerInstance.onerror = ...` in the creating script; I thought you were
referring to `self.onerror = ...` inside the worker.
More reason for an integer key, I guess. (Call it promiseId, presumably?) The
alternative would be not letting you catch such errors via
`workerInstance.onerror`, but I assume that would just complicate things and
fit poorly with any telemetry frameworks that try to collect errors from both
the window and any spawned workers.
