Copy over the error from inside workers to the Worker error event?

[domenic]

When an uncaught exception occurs inside a worker, it fires:

• An ErrorEvent "inside", on the WorkerGlobalScope object. The event.error property contains the exception value.

• An ErrorEvent "outside", on the Worker object. The event.error property is null.

(Relevant spec section)

This made sense, back before we had a way to serialize exceptions across thread boundaries. However, #4665 introduced that ability! So maybe we should consider setting the "outside" error property to a clone of the "inside" error property?

IMO this has a few prerequisites before I'd be fully comfortable with it:

• Figure out the interop issues mentioned in Fire an ErrorEvent instead an Event #2289. That is mostly about the error event fired during Worker initialization, which uses (per spec at least) Event instead of ErrorEvent, but interop issues in this area make me nervous about adding more.
• Try to get error serialization itself on better footing, per the stalled Expand JS error serialization #5749. /cc @syg @evilpie

[annevk]

cc @asutherland

[asutherland]

This definitely seems reasonable given the new serialization support. Thank you!

Offtopic-ish Aside: It might also be nice to consider improving the ergonomics around unhandledrejection so that they also could propagate to the Worker binding. I feel like the last time I looked at this it was necessary to add a handler in the worker that would then naively throw the rejection in order to get propagation. Propagation has been desirable at least in our own internal system code support infrastructure so that tests can fail with an explicit failure instead of mysteriously timing out when some very broken thing happens inside the worker, derailing it.

[RealAlphabet]

This definitely seems reasonable given the new serialization support. Thank you!

Offtopic-ish Aside: It might also be nice to consider improving the ergonomics around unhandledrejection so that they also could propagate to the Worker binding. I feel like the last time I looked at this it was necessary to add a handler in the worker that would then naively throw the rejection in order to get propagation. Propagation has been desirable at least in our own internal system code support infrastructure so that tests can fail with an explicit failure instead of mysteriously timing out when some very broken thing happens inside the worker, derailing it.

Would it be possible to take advantage of this to expose more information about the PromiseRejectionEvent event ? The same information currently exposed by ErrorEvent.

ErrorEvent.filename Read only
A string containing the name of the script file in which the error occurred.

ErrorEvent.lineno Read only
An integer containing the line number of the script file on which the error occurred.

ErrorEvent.colno Read only
An integer containing the column number of the script file on which the error occurred.