Re: [webidl] DOMException function definition makes no sense (#55)

OK. So, concretely, here are our two options, in terms of actual work:

1. Stay the course on consistifying DOMException with the rest of the platform's Error subclasses.
   - Probably best to update Web IDL to subsume the treatment of DOMException into that of Error, instead of having it as a distinct type. Since it calls super(), it has an [[ErrorData]], and can thus be treated entirely equivalently. And it doesn't have any extra branding data that could be used to distinguish.
   - All specs that reference the DOMException type would then be updated to reference the Error type. As far as I can tell this is only used for getters, callback params, and return values, so this should not change any normative behavior.
   - Implementers would need to make the relevant changes. In particular their binding code would need to have a custom Error subclass, implemented similar to TypeError or Promise, and then wired into the bindings code in the same way.
2. Give up on this and re-use existing Web IDL mechanisms.
    - The fact that we want the prototype to be Error.prototype (and probably we want class-side inheritance as well, i.e. `DOMException.__proto__ === Error`) means there needs to be *some* special code. We can't use `interface` or `: Error` directly.
    - IIRC old-Web IDL had an `exception` construct which was similar to `interface` in this way but had that special wiring. That might also be useful for stuff like https://github.com/w3c/mediacapture-main/issues/162
    - Bindings generators would presumably need to implement such a construct. It sounds like Blink and Gecko do already, in one form or another.
    - Once we have that construct we use it to define `DOMException` in Web IDL like other platform objects. No need for this "DOMException constructor object" or "DOMException prototype object" structure.

The delta between the two in terms of web-observable changes would be that:
- (1) has writable own-data properties for `code`, `name`, and `message`; (2) has proto-getters.
- (1) can be constructed without `new`, like other Error subclasses; (2) cannot.
- (1) has `Object.prototype.toString.call(de)` returning `"[object Error]"`, like other `Error` subclasses; (2) has it returning `"[object DOMException]"`.

Given the comparison between the amount of work involved here, it's hard for me to continue supporting (1). Especially since all of the deltas could in theory be addressed by extensions to Web IDL. So, I acede.

Can I turn over the work of making a spec-patch for (2) to someone else? Or is it my responsibility, as penance for introduce a nonsensical situation in the first place? ;) I'm especially unsure about the `exception` vs. `interface` construct and how we would do that.


---
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/55#issuecomment-121356652