- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 12 Sep 2014 15:57:44 -0400
- To: whatwg@lists.whatwg.org
On 9/12/14, 3:45 PM, Domenic Denicola wrote:
> var p = Promise.reject(new Error("boo"));
>
> setTimeout(() => {
> window.onrejectionhandled = () => console.log("got here");
> }, 100);
>
> setTimeout(() => {
> p.catch(() => {});
> }, 200);
That's a good proxy for what I was envisioning...
> In this case the event would be fired
By "the" event do you mean the error event or the rejectionhandled event?
> but no listener would be present at that time, so "got here" would not be logged.
In my mental model based on your initial mail here, the rejectionhandled
event would get fired at the point when catch() is called, which is
after window.onrejectionhandled is set.
>> 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.
We have both. self.onerror gets first dibs at the error, and if it
doesn't do anything to prevent the error propagating, then
workerInstance gets an error event fired at it.
> 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.
Yeah, I have no good insights into what, if anything, telemetry
frameworks do with error events on workers.
-Boris
Received on Friday, 12 September 2014 19:58:10 UTC