Skip to content
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

add [[ErrorData]] slot to DOMExceptions #1421

Merged
merged 1 commit into from
Dec 12, 2024
Merged

Conversation

ljharb
Copy link
Contributor

@ljharb ljharb commented Jul 18, 2024

This is an attempt to fix tc39/proposal-is-error#9.

The intention is to make DOM Exceptions true subclasses of Error.

It's possible this PR needs additional changes to simplify/undo #732 - I'm happy to make whatever changes are appropriate.

This is part of a stage 2 TC39 proposal for Error.isError. When it advances to stage 2.7, I'll file the appropriate implementation bugs.


Preview | Diff

@ljharb
Copy link
Contributor Author

ljharb commented Aug 27, 2024

ping @domenic @annevk, this proposal is on the agenda for advancement next plenary, and i'd love to know that this direction is acceptable :-)

@domenic
Copy link
Member

domenic commented Aug 27, 2024

Seems fine directionally. In general we want DOMException to behave as if its constructor had a super() call and I think this aligns with that.

Editorially I wonder if putting it as a step in https://webidl.spec.whatwg.org/#internally-create-a-new-object-implementing-the-interface would be better. (E.g. modifying step 4.)

I also don't understand the relationship to #732 (serializability).

@ljharb
Copy link
Contributor Author

ljharb commented Aug 28, 2024

How would you suggest I modify step 4?

The relationship to #732, as I understand it (but may indeed understand incorrectly) is that that PR was only necessary because DOMExceptions aren't proper Errors - but by making them proper Errors, then serialization of DOMExceptions should be automatic now?

@domenic
Copy link
Member

domenic commented Aug 28, 2024

How would you suggest I modify step 4?

By adding [[ErrorData]] to the argument list of MakeBasicObject, if the inclusive inherited interfaces of interface includes DOMException.

but by making them proper Errors, then serialization of DOMExceptions should be automatic now?

No, it's not automatic, and it should not be.

The relevant step is step 17 of https://html.spec.whatwg.org/#structuredserializeinternal. Thankfully, it's guarded by "and value is not a platform object", which means DOMException will properly go down to step 19 instead.

If we took the generic step 17 path for DOMException, we would lose the name information, and would look at the public message property instead of the internal message.

@ljharb
Copy link
Contributor Author

ljharb commented Aug 28, 2024

ah, gotcha. ok cool, i'll make those changes to step 4, thanks!

@ljharb
Copy link
Contributor Author

ljharb commented Aug 28, 2024

hmm - looking at the MakeBasicObject call, that seems like it's for all platform objects, not just DOMExceptions. Would something in https://webidl.spec.whatwg.org/#js-creating-throwing-exceptions make more sense?

If the MakeBasicObject call is correct, then how would I modify that to only add the slot for DOMExceptions and not for other things?

@annevk
Copy link
Member

annevk commented Aug 28, 2024

I'd put the list passed to MakeBasicObject in a variable and then conditionally append [[ErrorData]] to it.

@ljharb
Copy link
Contributor Author

ljharb commented Aug 28, 2024

Thanks, updated! I left the original note I added as informative, but can remove it if preferred.

@ljharb
Copy link
Contributor Author

ljharb commented Dec 9, 2024

This proposal is now stage 3. What are the next steps to getting this PR merged?

@domenic
Copy link
Member

domenic commented Dec 10, 2024

Implementer interest is the biggest checkbox in the OP that isn't checked. Maybe you can gather that in TC39? Ideally an explicit statement that the people implementing Error.isError() will also make sure the WPTs you've linked pass for DOMException.

@syg
Copy link
Contributor

syg commented Dec 10, 2024

For Chrome I'll make sure Error.isError returns true for DOMExceptions.

@dminor
Copy link

dminor commented Dec 11, 2024

For Firefox, we have https://bugzilla.mozilla.org/show_bug.cgi?id=1936385 filed, and the implementation looks straightforward, so we're also in support.

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Will merge once the rest of the checkboxes in the OP are filled out.

@ljharb ljharb mentioned this pull request Dec 12, 2024
1 task
@ljharb
Copy link
Contributor Author

ljharb commented Dec 12, 2024

done, if i got the n/a's right :-) thanks!

@domenic domenic merged commit acbbd5f into whatwg:main Dec 12, 2024
2 checks passed
@ljharb ljharb deleted the errordata branch December 12, 2024 05:49
@petamoriken
Copy link

For Deno, I have implemented it so that it returns true when V8 implements Error.isError.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

HTML integration
6 participants