Structured cloning of errors

[domenic]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: HTML, Web IDL
• Specification or proposal URL:
  • Allow structured cloning of native error types whatwg/html#4268
  • Define serialization and deserialization steps for Error whatwg/html#4665
  • Mark DOMException as serializable whatwg/webidl#732
• Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1556604
• Mozillians who can provide input (optional): @bzbarsky, @tschneidereit, @jorendorff

Other information

This is a proposal to make various error types structured cloneable, i.e. integrate them into the structured serialize/deserialize algorithms. In particular, this is done for DOMException in the fashion of any other Web IDL interface (via [Serializable]), and is done for ECMAScript's built-in error types in a way similar to other ECMAScript built-ins like Map or Set (as part of the structured (de)serialization algorithms in HTML).

There was some discussion on the best way to handle the ECMAScript built-in error types, as they are not separately branded (i.e. there is no internal state that distinguishes TypeError from URIError); see tc39/ecma262#1389 for that discussion.

@bzbarsky brought up some points about (de)serialization of the un-speced but de-facto stack property on errors. We've discussed and decided with option 1 in whatwg/html#4268 (comment), and I'll be updating the spec PRs shortly.

/cc @yutakahirano

[bzbarsky]

Fwiw, I think this is a good idea. Right now exception information can sort of make it out of a worker via "error" events on it, but when Promises are involved there's no good way I can see to propagate out error status. If the code could just postMessage the Error or DOMException involved, that would help the situation a good bit, I think.

[tschneidereit]

I also think this is a good idea, including the choice of option one with @domenic's added comment.

[yutakahirano]

I'll be updating the spec PRs shortly.

This is done.

[yutakahirano]

I have sent an intent-to-ship for this feature to blink-dev.
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/f8JngIi8qYs

[annevk]

Thanks all! I think the conclusion here is worth prototyping as important seems a tad overblown. I suspect we won't add it to the dashboard as this is a minor addition to an algorithm in the HTML Standard, but it does seem good (to me) to have reviewed it here. Shall we close this?