-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow structured cloning of native error types #4268
Comments
Hey folks, based on tc39/ecma262#1389 I think the best plan is as in the "Details" above, with "how to distinguish" solved by checking object.[GetPrototypeOf] vs. %TypeErrorPrototype%, %SyntaxErrorPrototype%, etc. I don't have time to drive this myself right now, but am happy to review patches toward it. /cc @ricea @yutakahirano. |
I'll try to make a PR. |
/cc @tschneidereit since this is streams-motivated, for Mozilla interest. @rniwa and @cdumez are my go-to folks for Safari, although @youennf may be the right contact again since this is streams motivated. Any interest from other browsers in allowing Errors to be structured cloned, thus allowing streams, and also user libraries, to signal errors better across worker or frame boundaries? |
CC @jorendorff, who's by now much more deeply involved in streams than I am. That said, I think this makes a lot of sense, and at least something in this direction is probably required to make streams transferable. |
There's an interesting problem here, which is that
|
Thanks for bringing that up, @bzbarsky. I see a few options:
Do you (or @yutakahirano) have thoughts on the better approach here? |
I think option 1 is fine and slightly more forward-compatible to when |
Oh, just saw option 3. I would probably be OK with it if we need to go there, but it seems suboptimal from a web developer point of view. |
I like option 3 as a first step. Errors are not at all clonable today, and this can be a good first step. We will be able to contain I cannot imagine someone depends on the assumption that cc: @nhiroki |
Hmm. Although I can understand if Chrome does not want to also serialize stack in their first implementation, I am hesitant to have the spec prohibit Firefox from serializing stack in their first implementation, if that's their preference. Do you have objections to option 1? I suppose we could also do a variant of option 1, with "may" instead of "should". |
I'm OK with option 1. As there is no way to test the implementation regarding the point, the difference will be a sentence in the spec text. |
Well, I think we will probably add a test that .stack is the same, but in a different file since it is only a "should" and relies on shaky spec foundations. @bzbarsky / @tschneidereit / @jorendorff, is Mozilla "interested" in this feature, i.e. thinks it should land in the spec? I can post to mozilla/standards-positions if that'd be helpful. |
@domenic Please go ahead and post to mozilla/standards-positions. Speaking for myself, I think it's a good idea, and I'm in favor of option 1 and your last comment. |
@jakearchibald shared https://www.w3.org/Bugs/Public/show_bug.cgi?id=28389 with me the other day. It seems there was some concern about accidental sharing of information, but nobody really objected. And there was still the idea that TC39 would take on this algorithm and make it more holistic. And I ended up closing it as WONTFIX since I didn't see that using the prototype could work. |
stack is unspecified in the language, but will be at some point; it would be helpful to avoid adding additional constraints on doing so. |
@ljharb can you say more about what kinds of constraints you're concerned about here? |
for one, being able to construct an Error with an ErrorData internal slot that contains stack info that might have been doctored manually - ie, as opposed to being only provided by the engine. |
Define serialization and deserialization steps for all built-in NativeError types from the JavaScript specification. This change doesn't cover DOMExceptions, which are covered by whatwg/webidl#732. Fixes #4268. Tests: * web-platform-tests/wpt#17095 * web-platform-tests/wpt#17159
Fixes #729. See also whatwg/html#4268. Tests: * web-platform-tests/wpt#17095 * web-platform-tests/wpt#17159
Over in whatwg/streams, we're working on making streams transferable. One important missing feature right now is the ability to transfer errors across the realm boundary. For example, if you do the following:
The
// (*)
line should result in a cloned version of theError
instance being thrown.Although we could add hacky serialization to the internals of streams for this case, we think it'd be simpler and nicer to allow cloning error instances across the platform. I expect it to be especially beneficial for library developers who want to properly forward errors from a worker to the main page, for example.
Details:
new TypeError()
fromnew SyntaxError()
. We could:Error
, copying only the message..name
property and use that, ensuring we fall back to"Error"
if it's not on the safelist of known native error types.constructor
property and compare that to a safelistTypeError
except by structured cloning it and seeing what comes out the other side. Right now there's no real concept of something being "really" aTypeError
, and perhaps things should stay that way.Opinions welcome on what to do with error types. I think I'd probably start with either deserializing everything to
Error
, or checking.name
, and in parallel work with TC39 to see what they think about a stronger approach.The text was updated successfully, but these errors were encountered: