Re: [whatwg/webidl] Normative: Add DOMException cause (PR #1179)

@bathos
> “just pass it to super()”. Is it a pain for implementors?

Conceptually, no, unfortunately the reality is a bit different. For those of us who implement `DOMException` in C++ using v8's APIs -- which do not provide any mechanism at the C++ level to invoke the `Error` constructor easily -- we can't simply "pass it to super()"... but that's an implementation problem.

The key issue here for me is that `DOMException` taking the getter/setter route when all other standardized Error types use the own property route means that users will be forced to either special case `DOMException` in error handling logic or otherwise be forced to always handle things the way `DOMException` does, eroding the language level guarantee guarantees.

For example,

```
try {
  doSomething();
} catch (err) {
  // It's now completely ambiguous what 'cause' in err means.

  // I either have to...

  if (err instanceof DOMException) {
    // 'cause' in err is meaningless.
  } else {
    // 'cause' in err has semantic value
  }

  // or always assume 'cause' in error is meaningless.
}
```

This difference does not just apply to non-browser runtimes. Browser developers will face this same issue. As the other runtimes also implement this, the fact that DOMException does it differently means that developers in general will not be able to rely on it.

Now, that said it's absolutely true that JavaScript allows you to throw literally anything so it can be argued that the mechanism is already unreliable, but since `DOMException` extends from `Error`, it really ought to follow the language specified contract for `Error` or it otherwise should not claim to *be* an `Error`.

```js
const ex = new DOMException();
ex instanceof Error;  // true
```


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1179#issuecomment-1255619403

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1179/c1255619403@github.com>

Received on Thursday, 22 September 2022 22:25:54 UTC