Error.isError does not detect legacy Error types using util.inherits

[arciisine]

Version

v25.8.0

Platform

Darwin mac.lan 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:55:08 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6020 arm64

Subsystem

No response

What steps will reproduce the bug?

Sample REPL output

> function CustomError() {}
undefined
> require('util').inherits(CustomError, Error);
undefined
> new CustomError() instanceof Error
true
> Error.isError(CustomError)
false

How often does it reproduce? Is there a required condition?

This happens 100% of the time

What is the expected behavior? Why is that the expected behavior?

Error.isError is meant to be a more robust replacement for Error detection vs instanceof. It should work consistently with legacy node patterns utils.inherits, without surprise.

What do you see instead?

Error.isError does not detect error types that rely on utils.inherits for extension. instanceof Error does still work in these scenarios.

Additional information

The es-shim, https://github.com/es-shims/Error.isError/blob/main/implementation.js#L64 , has the instanceof Error behavior as the final fallback, which would catch this behavior.

[Renegade334]

This is specified behaviour:

Error.isError() rejects values that aren't actual Error instances, even if they have Error.prototype in their prototype chain — instanceof Error would accept these as it does check the prototype chain.

This is exactly the same check that util.types.isNativeError() performs.

If you are using error objects constructed in that way, then you can't use Error.isError() to test for them.

[ljharb]

The es-shim package is best-effort, and it's unfortunate that it does "catch this behavior" - it shouldn't.

[arciisine]

So the problem for me, is that this is from a third party library. Knowing the construction method of an error is a high bar to put on library consumers. This means every use of isError needs to be researched to determine is it's acceptable or every call site needs to have a logical or with an instanceof check.

[Renegade334]

Ultimately, if you are just trying to detect whether an object is derived from Error.prototype, you should be using instanceof.

Error.isError() is for realm-agnostic detection of objects constructed by the Error constructor, which is not the usage case you're describing. It's telling you that the objects you are passing it are not built-in Error objects, which is exactly its purpose.

[arciisine]

Appreciate the discussion, and understood on the goal for it to provide type checking across realms. Hopefully this is a legacy issue that will only decrease in frequency, as I presume more and more people will reach for Error.isError by default, regardless of use case.