JavaScript’s Error.isError(): A New Era for Cross-Realm Error Checking

In the ever-evolving world of JavaScript, the recent advancement of Error.isError() to Stage 4 at TC39 marks a major milestone in error handling. This simple yet powerful method promises to revolutionize how developers detect error instances, especially in complex environments where multiple execution contexts (or realms) coexist.

Let’s break it down.

The Problem with instanceof

For years, instanceof has been the go-to tool for determining if a value is an instance of Error:

if (err instanceof Error) {
  // Handle the error
}

This works well in most cases, but it breaks when dealing with multiple realms. Imagine a scenario where an error originates from:

• An iframe embedded in a webpage.
• A Web Worker operating in a separate thread.
• A Node.js VM context used for sandboxing.

In these cases, err instanceof Error returns false, because each realm has its own global object, including its own Error constructor. This discrepancy makes robust cross-realm error detection difficult and error-prone.

The Solution: Error.isError()

Enter Error.isError(). This method works similarly to Array.isArray() by checking an internal slot that marks an object as an error, regardless of its realm of origin.

Here’s how it works:

const iframe = document.createElement('iframe');
document.body.appendChild(iframe);

const err = new iframe.contentWindow.Error('Cross-realm error');
console.log(Error.isError(err)); // true 🎉

With Error.isError(), realm boundaries disappear for error detection. This not only simplifies your code but also enhances the robustness of error handling across different contexts.

Beyond the Basics

While this change might seem small, its implications are significant:

• Library authors no longer need to roll their own cross-realm detection logic. Popular libraries like Lodash and Ramda can simplify their error-checking utilities.
• Frameworks and tools (like testing frameworks or logging systems) can more reliably identify errors thrown in sandboxes or worker threads.
• Security-conscious environments (such as sandboxed runtimes) will benefit from more consistent error handling.

Additionally, this method aligns with best practices for JavaScript, where built-in solutions (like Array.isArray) are preferred over custom implementations.

Other Considerations

1. Compatibility: Since this feature just reached Stage 4, expect it to be part of an upcoming ECMAScript edition (likely ES2026). Browser and runtime adoption will follow, but until then, you’ll need to polyfill this behavior if you want to use it today.
2. Polyfill Availability: Here’s a simple polyfill you can drop into your codebase:

if (!Error.isError) {
  Error.isError = function (value) {
    return Object.prototype.toString.call(value) === '[object Error]' ||
           value instanceof Error;
  };
}

This isn’t perfect, but it covers most cases for now.

3. Performance Impact: Using Error.isError() eliminates the need for multiple instanceof checks or fallback heuristics, potentially reducing overhead in error-heavy code paths.
4. Future Enhancements: Now that Error.isError() sets a precedent, we might see similar methods for other cross-realm checks, like Map.isMap() or Set.isSet() in the future. TC39 could expand this approach.

Finally

The introduction of Error.isError() is a welcome and long-overdue improvement to JavaScript. By offering a reliable, realm-agnostic way to detect errors, it makes life easier for developers working in complex environments, from iframes to workers, from Node.js sandboxes to cross-origin applications.

While this feature might seem niche at first glance, it represents a broader philosophy shift: making JavaScript more predictable and developer-friendly across different execution contexts.

So, keep an eye out for Error.isError() in upcoming browser releases and JavaScript runtimes. In the meantime, consider polyfilling it if you’re dealing with cross-realm error detection today.

Support Us