-
-
Notifications
You must be signed in to change notification settings - Fork 2
Description
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.toStringTagtag specifically in the case ofDOMException*, which would fail onDOMExceptions with spoofedtoStringTagor other objects withtoStringTagspoofed as "DOMException" - Bring forward
instanceofchecking specifically in the case ofDOMException*, which would fail on cross-realmDOMExceptions. I guess this can't be tested for in Node asrequire('vm').runInNewContext('new DOMException()')givesDOMException is not defined, but such cross-realmDOMExceptions are presumably pretty commonplace in browsers (e.g. anyDOMExceptionoriginating from aniframe)
* and maybe DOMError and/or Exception too?