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
