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

Spinning this off from #1211 since I think it deserves its own discussion:

@dandrader made me aware that the case he's working on is unlike [`RTCError`](https://w3c.github.io/webrtc-pc/#dom-rtcerror) or [`WebTransportError`](https://w3c.github.io/webtransport/#web-transport-error-interface) (or the pull request's `WidgetError`) in that he basically just needs more error types.

Specifically, his case is a smart card API, which has ~15 different SmartCard-specific error codes. (It seems like the plan is to expose a subset of [these](https://pcsclite.apdu.fr/api/group__ErrorCodes.html) to the web.)

I see several routes we could go for this sort of API:

1. Encourage a subclass of DOMException, e.g. `SmartCodeError`, with a separate `responseCode` property which is one of the ~15 values.
2. Add ~15 new smartcode-specific error names to Web IDL, e.g. "SmartCardNotReady", "SmartCardProtoMismatch", etc.
3. Add ~10 new smartcode-specific error names to Web IDL, by having the SmartCard spec reuse some of the existing Web IDL error names. (Such as "NotFoundError" for `SCARD_E_NO_SMARTCARD`, or "NotAllowedError" for `SCARD_E_SHARING_VIOLATION`.)
4. Let other specs, such as the SmartCard spec, use arbitrary error names, without Web IDL requiring them to be in the table. (This could have subvariants corresponding to (2) and (3), but the main thing is, Web IDL wouldn't coordinate.)
5. Have some minimal coordination/registration where other specs reserve "namespaces", e.g. "SmartCard*Error".

At first I was pushing for (1), but now I'm thinking one of the other options might be better. Especially since it's weird for an error to have three subtypes: `DOMException` > `name = "SmartCardError"` > `responseCode = "not-ready"` seems a bit excessive, compared to idiomatic JavaScript errors which just have one level (`TypeError`, `SyntaxError`, etc.).

Some prior art:

- There are several error codes in Web IDL which are clearly IndexedDB-specific or DOM-specific.
- https://wicg.github.io/serial/ just makes up several error names: "BufferOverrunError", "BreakError", "FramingError", "ParityError". (It also uses many other existing names, such as "InvalidStateError", "NetworkError", "SecurityError".) /cc @reillyeon

What do others think? I guess the main questions are: (a) should `DOMException`'s `name` be reserved for generic broad categories, or is it OK to allow spec-specific error names; and (b) if we do allow spec-specific error names, should Web IDL's error names table act as a coordination point, or should we just let specs do what they want?

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

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

Received on Sunday, 16 October 2022 10:08:05 UTC