Re: [whatwg] An API for unhandled promise rejections

From: Boris Zbarsky [mailto:bzbarsky@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.

Received on Friday, 12 September 2014 19:46:13 UTC