Re: [whatwg/webidl] What to do about specs that need lots of error types (Issue #1219)

> I tend to see it as only two levels, name and responseCode. At least without cross-global instanceof you wouldn't want to rely on that.

The first level is reliable cross-realm using `.constructor.name`. (For JS spec exceptions, `.constructor.name === .name`, but `DOMException`s departed from that... [ah, memories](https://esdiscuss.org/topic/creating-your-own-errors#content-7).)

> I guess it depends a bit on the exact use cases and how developers are expected to deal with it. Also, do they need to branch on things besides smartcode-specific exceptions, e.g., "SyntaxError" or "InvalidStateError"?

@dandrader knows the specific case better, but I could easily imagine some sort of "get me a smartcard" API which can fail with:

- `TypeError` because you typoed it as `getMeASmartCrd()`. (Developers want to "branch" on this by not catching it and letting it hit `window.onerror`.)
- `"NotAllowedError"` `DOMException` because the user denied permission. (Developers want to branch on this and say "no, please click 'ok' to the permission prompt next time!")
- A variety of SmartCard-specific errors, e.g. corresponding to `SCARD_E_NO_SMARTCARD` or `SCARD_E_NOT_READY`, which they branch on to translate into friendlier user-specific errors.

Similar patterns can be seen with the Web Serial case, where I am pretty sure @reillyeon added the separate errors because developers are expected to take different actions depending on them. And #1168 indicates a desire to distinguish two different types of aborts, one where the user presses "Cancel" and one where the user opts out of the process (which is, somehow, different?).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1219#issuecomment-1284791335
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1219/1284791335@github.com>