In JavaScript, a caller writes `err instanceof ValidationError` and gets false even though the code that threw called `new ValidationError(...)`. What can make that check fail, and how would you discriminate error types more robustly?

## What `instanceof` actually asks `err instanceof ValidationError` does not ask "does this object look like a validation error". It walks `err`'s prototype chain and asks whether the specific object currently held in `ValidationError.prototype` appears in it. That is an identity comparison between two object references. It is exact, fast, and completely dependent on both sides referring to the *same* class object. Every failure mode below is a variation on "they don't". ## Failure mode 1 — two constructor objects for one class The most common cause in real systems is duplication. A dependency graph can resolve two versions, or even two copies of the same version, of the package that defines `ValidationError`; a bundler can inline the module into two chunks; a mixed ESM/CommonJS setup can evaluate the same file twice under two specifiers. Each evaluation creates a fresh class object with a fresh `.prototype`. ```js // Two evaluations of the same source produce unrelated classes. const A = class ValidationError extends Error {}; const B = class ValidationError extends Error {}; new A('x') instanceof B; // false — same name, different identity ``` The symptom is maddening because everything *looks* right: the name matches, the message matches, the source is one file. Only the identity differs. Module resolution and bundling decide this, which means a check that passes in one build can fail in another with no source change. ## Failure mode 2 — separate realms A realm has its own complete set of intrinsics: its own `Error`, `Array`, `Object`. An object created in one realm and passed into another carries its original prototype chain, which contains that realm's `Error.prototype`, not yours. So `err instanceof Error` itself can be false for an error that came from a different realm, and a subclass check certainly is. This is the same mechanism behind the classic `Array.isArray` existing at all — the language provides realm-independent tests precisely because `instanceof` is not one. ## Failure mode 3 — a downlevelled subclass If the class was compiled to ES5, `super` does not exist and the generated constructor calls `Error.call(this)`. The built-in `Error` ignores the `this` it is handed and returns a new object, so the instance never gets the subclass prototype. The repair is an explicit `Object.setPrototypeOf(this, new.target.prototype)` inside the constructor. Errors constructed before that line was added will fail the check. ## Failure mode 4 — the value crossed a boundary If the error was serialized and revived — sent over a network, written to a queue, put through a structured copy — what you hold is a new object built by generic machinery. It may have the right `message` and even the right `name`, but it was never constructed by your class, so no prototype link exists. ## Robust alternatives, from weakest to strongest **Compare `err.name`.** Cheap and survives all four failures, because the string travels with the data. Its weakness is that `name` is an ordinary writable string with no namespace: two independent libraries can both ship a `ValidationError`, and any code can overwrite the property. Treat it as a hint for humans and logs rather than a security-grade discriminant. **Use a documented `code` string.** A stable, namespaced constant you set in the constructor — `'MYLIB_VALIDATION'` — and publish as part of the API. It is data, so it survives serialization; it is namespaced, so collisions are your own fault; and callers can `switch` on it. This is the pattern most widely deployed error surfaces settle on. ```js class ValidationError extends Error { constructor(message, field) { super(message); this.name = 'ValidationError'; this.code = 'MYLIB_VALIDATION'; this.field = field; } } ``` **Export a type guard.** Ship `isValidationError(err)` from the module that owns the class and tell consumers to call it instead of using `instanceof`. The advantage is that the check becomes yours to define: today it can be `instanceof`, tomorrow a brand check, and no consumer has to change. **Brand with a registered symbol.** `Symbol.for('mylib.validationError')` looks the key up in the global symbol registry, which is shared across realms, so two copies of your library — even in different realms — obtain the *same* symbol. Set that key as a property in the constructor and have the guard test for it: ```js const BRAND = Symbol.for('mylib.validationError'); class ValidationError extends Error { constructor(message) { super(message); this.name = 'ValidationError'; this[BRAND] = true; } } export function isValidationError(err) { return typeof err === 'object' && err !== null && err[BRAND] === true; } ``` This survives duplicate module copies, realm boundaries, and downlevelled builds. It does not survive a plain JSON round trip — symbol keys are not serialized — which is a reminder that in-process identity and over-the-wire identity are different problems needing different fields. ## What to standardise Pick one discriminant per boundary and publish it. Inside a single module or application `instanceof` is fine and reads best. At a *published* boundary — a library others install, a plugin interface, anything that might be loaded twice — prefer an exported guard backed by a brand, and always carry a string `code` for the cases where the value has become plain data.