Re: [whatwg/webidl] Allow DOMException subclasses to be used as exceptions (PR #1211)

@domenic commented on this pull request.



> +    [=deserialization steps=] preserve the additional information.
+
+<p class=note>These requirements mean that the inherited {{DOMException/code}} property of these
+interfaces will always return 0.
+
+<div class=example id=example-domexception-derived-interface>
+    The definition for a {{DOMException}} derived interface which carries along an additional
+    "hardware error code", for interfacing with a hypothetical Widget hardware device, could look
+    something like this:
+
+    <pre highlight=webidl>
+        [Exposed=Window]
+        interface WidgetError : DOMException {
+          constructor(optional DOMString message = "", WidgetErrorOptions options);
+
+          readonly attribute unsigned long long hardwareErrorCode;

I'm kind of envisioning this being some opaque number spit out by the widget hardware. I can see how maybe that's not a good pattern to have as our only example, as we'd arguably want to have a web platform API abstract over that sort of thing (like the SmartCard proposal is doing).

Using an enum, to me, gets into #1219, which I don't consider quite settled yet.

We should probably change this to be some number spit out by a protocol, instead of by a widget, since that's a bit more respectable and has precedent in both RTCError and WebTransportError.

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

Message ID: <whatwg/webidl/pull/1211/review/1159458895@github.com>