How Lodash _.isError Identifies Error Objects

In JavaScript development, reliably identifying error instances across diverse runtime environments presents subtle but significant challenges. This article examines the mechanics of Lodash’s _.isError function, explaining why conventional methods like instanceof fall short, how Lodash leverages internal object tagging to achieve cross-realm reliability, and what makes this utility the standard for detecting native, subclassed, and host-specific error objects.

The Limitation of instanceof Error

The native approach to checking errors in JavaScript is typically the instanceof operator:

value instanceof Error

While functional in simple applications, instanceof relies entirely on the prototype chain within the current execution context. It fails in multi-realm environments, such as applications utilizing <iframe> elements, Node.js vm contexts, or Web Workers.

If an error is thrown inside an <iframe> and passed to the parent window, the error inherits from the iframe's Error.prototype, not the parent window's Error.prototype. Consequently, instanceof Error evaluates to false, even though the object is functionally and structurally an error.

Deep Internal Tag Inspection via toStringTag

To circumvent prototype isolation, Lodash relies on the internal [[Class]] property exposed through Object.prototype.toString.call(value).

Regardless of which realm or window an error originated from, native error objects return a specific internal tag:

Object.prototype.toString.call(new Error()) // "[object Error]"

Lodash’s _.isError verifies that the incoming value is an object-like structure (non-null and typeof equals 'object') and evaluates its internal tag. This guarantees that TypeError, SyntaxError, RangeError, ReferenceError, and all other native variants are recognized universally, irrespective of memory boundaries or execution contexts.

Handling Host Objects and DOMException

Modern web platforms include error types that do not always inherit cleanly from the ECMAScript Error base class, such as browser-level DOMException instances.

Lodash accounts for these edge cases by checking for standard error tags as well as specific platform implementations. Under the hood, modern versions of Lodash check whether the tag matches [object Error] or [object DOMException], ensuring platform-level asynchronous errors (like aborted fetch requests) are not misclassified as plain objects.

Structural Fallback for Custom and Subclassed Errors

In environments where Symbol.toStringTag might be overridden or transpilation tools alter class inheritance, simple string matching can occasionally be manipulated. Lodash addresses this by pairing tag verification with structural checks:

1. Object Validation: Ensures the value is not null and of type object.
2. Tag Matching: Confirms the tag resolves to an error signature.
3. Property Verification: Where required, checks for the presence of intrinsic error properties—such as message and name—and confirms that the prototype descends from an error-like structure.

By decoupling error identification from the execution context's prototype chain and relying on standard internal tags, _.isError provides an environment-agnostic, cross-realm solution that vanilla JavaScript checks cannot natively guarantee.