JavaScript’s error handling system has long had a blind spot when dealing with errors across different execution contexts. The new Error.isError() method addresses this limitation, providing developers with a more reliable way to identify error objects.

The traditional approach to checking if a value is an Error has been using the instanceof operator.

1
try {
2
  // Code that might throw
3
} catch (e) {
4
  if (e instanceof Error) {
5
    // Handle error
6
  }
7
}

This approach has two significant limitations:

1. Cross-realm errors aren’t correctly identified. When an error originates from another realm (like an iframe or VM module), instanceof Error returns false because each realm has its own Error constructor.

This can lead to situations where errors are not handled correctly, as the instanceof check fails.

2. Fake errors can pass the test. Objects with Error.prototype in their prototype chain but lacking error characteristics will be incorrectly identified as errors.

These issues can lead to inconsistent error handling and difficult-to-diagnose bugs. The new Error.isError() method provides a solution:

Instead of checking the prototype chain, Error.isError() uses a simpler and more reliable approach. It looks for a special internal marker (like a hidden ID tag) that gets added to every genuine Error object when it’s created.

This method works better than instanceof for two reasons:

1. It correctly identifies errors even when they come from different contexts (like iframes or modules)
2. It rejects fake objects that try to pretend they’re errors by manipulating the prototype

Think of it like checking for a manufacturer’s watermark instead of just looking at the label - it’s much harder to fake.

Typing Error.isError()

Here’s one way you could type the Error.isError() method in TypeScript: