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

Handle errors according to Web IDL conventions #314

Closed
zolkis opened this issue Dec 13, 2022 · 3 comments
Closed

Handle errors according to Web IDL conventions #314

zolkis opened this issue Dec 13, 2022 · 3 comments

Comments

@zolkis
Copy link
Collaborator

zolkis commented Dec 13, 2022

When handling errors, the spec should follow the Web IDL convention:

Simple exceptions can be created by providing their error name. A DOMException can be created by providing its error name followed by DOMException. Exceptions can also be thrown, by providing the same details required to create one.

@anssiko
Copy link
Member

anssiko commented Dec 13, 2022

Thanks for filing this.

We should align both the simple exceptions and DOMException usage with conventions. Here's my understanding:

Simple exceptions are created with a "new" keyword because they're ECMAScript error types. IOW, in JS console this test should be true: typeof new TypeError === 'object'.

To create a new DOMException with any of these names we don't use the "new" keyword but the "newly created" syntax:

To create a new DOMException with error name "SyntaxError":
Let object be a newly created "SyntaxError" DOMException.

Please investigate that my understanding is correct and once you're confident apply the conventions to the whole spec.

@zolkis
Copy link
Collaborator Author

zolkis commented Dec 13, 2022

The spec prose to be used, as also done in html, infra, fetch etc. specs:

  1. For simple exceptions,

throw a {{TypeError}}

or

reject |promise| with a {{TypeError}}

  1. For DOMExceptions,

throw a "{{SecurityError}}" {{DOMException}}

or

reject |promise| with a "{{SecurityError}}" {{DOMException}}

@anssiko
Copy link
Member

anssiko commented Dec 13, 2022

Thanks for checking the other specs too, that looks right to me.

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

No branches or pull requests

2 participants