isError returns false for DOMException instances

[lionel-rowe]

isError returns false for DOMException instances.

From what I can see, there are three reasons for this:

Error.isError/implementation.js

Lines 22 to 24 in 059b44a

	if (isNativeError) { // node 10+
	return isNativeError(arg);
	}

In NodeJS, require('util').types.isNativeError(new DOMException()) gives false.

Error.isError/implementation.js

Lines 26 to 28 in 059b44a

	if ($structuredClone) {
	try {
	return $structuredClone(arg) instanceof $Error;

In current server-side implementations (pending whatwg/webidl#1421), structuredClone(new DOMException()) returns {}, i.e. a plain JS object.

Error.isError/implementation.js

Lines 34 to 37 in 059b44a

	if (!hasToStringTag || !(Symbol.toStringTag in arg)) {
	var str = $toString(arg);
	return str === '[object Error]' // errors
	|| str === '[object DOMException]' // browsers

Even if this line was hit (which it won't be because the previous two lines would both return early with false), Symbol.toStringTag in new DOMException() returns true, so the condition fails.

It doesn't seem there's any 100% foolproof way of detecting DOMExceptions until whatwg/webidl#1421 lands in implementations, so you could either:

• Be lax with Symbol.toStringTag tag specifically in the case of DOMException*, which would fail on DOMExceptions with spoofed toStringTag or other objects with toStringTag spoofed as "DOMException"
• Bring forward instanceof checking specifically in the case of DOMException*, which would fail on cross-realm DOMExceptions. I guess this can't be tested for in Node as require('vm').runInNewContext('new DOMException()') gives DOMException is not defined, but such cross-realm DOMExceptions are presumably pretty commonplace in browsers (e.g. any DOMException originating from an iframe)

* and maybe DOMError and/or Exception too?

[ljharb]

Given that it's bizarre to even have DOMException in node, and given that there's just no way to robustly detect it, I don't think that's a case worth worrying about (however, you may want to file it as a bug in node for util.types.isNativeError)

[lionel-rowe]

it's bizarre to even have DOMException in node

IMO it's bizarre to have DOMException anywhere, it's just a badly designed API (badly named, weird semantics, weird behavior). But it's a commonly encountered error subtype, and no weirder that it exists in NodeJS than anywhere else. Bear in mind many DOMExceptions have nothing to do with the DOM, hence why it's badly named.

const ac = new AbortController()
ac.abort()
ac.signal.reason instanceof DOMException // true

[ljharb]

yeah, that's part of the weirdness of AbortController, via fetch - it should never have been a DOMException.

Unless node offers a way to robustly identify it, though, I'm not sure if we should do anything for it.

[lionel-rowe]

I don't think it's particularly to do with fetch, as AbortController and AbortSignal have other use cases too, e.g. canceling event listeners.

Other non-DOM-related and non-fetch-related APIs also produce DOMExceptions:

• structuredClone({ fn: () => {} }) throws a DataCloneError DOMException
• atob('!') throws an InvalidCharacterError DOMException
• There are also various DOMException types produced from IndexedDB operations, although those are only relevant to browsers (but again, not DOM-related)

[ljharb]

I'm just talking about the history - Abort things were built to provide cancellation to fetch, initially. That there are many other use cases is why using DOMException made no sense. Similarly, anything that's not DOM-related simply shouldn't be throwing an error named "DOM" ¯\_(ツ)_/¯ but that ship has sailed.

Regardless of what the behavior is here, I'd love to add test cases for all of those if you want to submit a PR.