Proposal:https://github.com/tc39/proposal-is-error

Stage: 3

In our previous post, we examined the Atomics.pause feature and how it can improve asynchronous task management in JavaScript. Building on that discussion of enhancing the developer experience, we now turn to Error.isError, another emerging TC39 proposal that addresses a different yet equally significant challenge.

Error handling is a fundamental aspect of robust application development. However, identifying an Error object reliably becomes challenging in complex JavaScript environments involving multiple realms (like iframes, workers, or Node.js VM contexts). The Error.isError proposal introduces a straightforward and standard method to check if a value is an Error, regardless of the realm it originated from.

The Problem

In JavaScript, the common way to check if a value is an Error is by using the instanceof operator:

However, this method has limitations in environments with multiple realms. Each realm in JavaScript has its own set of built-in objects, including the Error constructor. An Error object created in one realm doesn't pass the instanceof Error check in another realm:

This inconsistency arises because errorInA is an instance of RealmA.Error, not RealmB.Error. As a result, developers cannot reliably detect Error objects across realms, leading to unhandled errors and unpredictable behavior in applications that rely on cross-realm interactions.

Moreover, with the introduction of Symbol.toStringTag, methods like Object.prototype.toString are no longer reliable for brand checking, as the toString result can be spoofed.

Syntax and Examples

To address these issues, the Error.isError proposal introduces a static method that provides a reliable way to determine if a given value is an Error object, regardless of the realm or any Symbol.toStringTag spoofing.

Syntax

This method returns true if value is an instance of Error or any of its subclasses, even if it comes from a different realm.

Example

The method checks for the presence of the internal [[ErrorData]] slot, which is a part of the specification for Error objects and their subclasses. This internal slot is not accessible or spoofable from JavaScript code, ensuring the reliability of the check.

Use Cases

Cross-Realm Error Handling

In applications that use iframes, web workers, or other multi-realm setups, errors can originate from different realms. Using Error.isError ensures that these errors are correctly identified and handled.

Library Development

Library authors often need to handle errors that could originate from various environments. Using Error.isError allows libraries to robustly detect and handle errors without worrying about the realm in which they were created.

Serialization and Structured Cloning

Platforms that need to serialize values safely, such as certain server environments or tools like RunKit, can use Error.isError to identify Error objects accurately before serialization.

In the context of the structuredClone method—which has special behavior for Error objects—developers can predict whether the special handling will be applied.

Potential Pitfalls

While Error.isError offers a more reliable way to detect Error objects, there are some considerations:

Not Yet Standardized: As of now, Error.isError is still a proposal. It is not available in all JavaScript environments. Developers should check for support or consider polyfills.

Custom Error Objects: Objects that mimic Errors but don't inherit from the standard Error prototype chain won't be recognized by Error.isError. This method checks for the presence of the internal [[ErrorData]] slot, which custom error-like objects might not have.

Conclusion

The Error.isError proposal represents a significant advancement in improving error handling reliability and consistency in JavaScript, particularly for applications that operate across multiple realms. By introducing a standardized method to identify Error objects—including subclasses and cross-realm instances—it streamlines error detection and management across diverse execution contexts. This proposal addresses a long-standing challenge, making it easier for developers to handle errors robustly and consistently in complex environments.