First, I am delighted that this proposal reached stage 1 recently. I implemented support for printing aggregated errors to the console in Jest and faced difficulties determining whether an object was an error. You may want to add this to the list of use cases. In that process, I learned about Node's util.types.isNativeError(value), which you could add as prior work.
I also found out that several popular libraries and frameworks (e.g. Axios) create errors that are not returned by the Error constructor but merely are instanceof Error. You can find these libraries by searching for Error.call(this) on Sourcegraph.
That means that people will see the following behavior:
Those examples aren't native errors though, so the instanceof check would be wrong. Libraries like that need to do class extends Error if they want the native branding.
First, I am delighted that this proposal reached stage 1 recently. I implemented support for printing aggregated errors to the console in Jest and faced difficulties determining whether an object was an error. You may want to add this to the list of use cases. In that process, I learned about Node's
util.types.isNativeError(value)
, which you could add as prior work.I also found out that several popular libraries and frameworks (e.g. Axios) create errors that are not returned by the
Error
constructor but merely areinstanceof Error
. You can find these libraries by searching forError.call(this)
on Sourcegraph.That means that people will see the following behavior:
This could confuse people. It might be worth including an
instanceof
check in Error.isError().I've also written an extensive article about how to test if an object is an error if people are interested.