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:57:44 -0400
Message-ID: <54135038.1010701@mit.edu>
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.

Received on Friday, 12 September 2014 19:58:10 UTC

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