In JavaScript, given `class ValidationError extends Error {}`, the expression `new ValidationError('bad email').name` evaluates to "Error" rather than "ValidationError". Why, and what does a correctly written custom error class set?

## What `extends Error` gives you, and what it doesn't With a native ES2015+ class, `class ValidationError extends Error {}` already does more than people assume. The implicit derived constructor forwards its arguments to `super`, so `new ValidationError('bad email').message` is `'bad email'`. The instance's prototype is `ValidationError.prototype`, so `instanceof` works for both the subclass and `Error`. Engines attach their usual diagnostic properties. What it does *not* do is invent a `name`. ## Where `name` actually lives `name` is an ordinary string data property. `Error.prototype.name` is `"Error"`; `TypeError.prototype.name` is `"TypeError"`, and so on — the built-in subtypes each shadow it deliberately. Your subclass's prototype object has no `name` of its own, so a property lookup on the instance walks `instance → ValidationError.prototype → Error.prototype` and finds `"Error"`. ```js class ValidationError extends Error {} const e = new ValidationError('bad email'); e.message; // "bad email" e.name; // "Error" Object.hasOwn(ValidationError.prototype, 'name'); // false e instanceof ValidationError; // true ``` The class *does* have a name — `ValidationError.name` is `"ValidationError"` — but that is the function's own `name` property, and nothing copies it onto instances. ## Why it matters beyond cosmetics `Error.prototype.toString()` is `name + ": " + message`, and that is what you see when the error is interpolated into a string, concatenated into a log line, or printed by a top-level handler. Leave `name` unset and every custom error in your logs is labelled `Error: ...`, erasing exactly the distinction you created the class to express. Code that discriminates on `err.name` — a common pattern at package boundaries — gets the wrong answer too. ## Three ways to set it ```js // 1. On the instance, in the constructor. class ValidationError extends Error { constructor(message, field) { super(message); this.name = 'ValidationError'; this.field = field; } } // 2. On the prototype, once. class ParseError extends Error {} ParseError.prototype.name = 'ParseError'; // 3. From new.target, so subclasses stay correct. class AppError extends Error { constructor(message) { super(message); this.name = new.target.name; } } class NotFoundError extends AppError {} new NotFoundError('missing').name; // "NotFoundError" ``` Option 3 works because `new.target` inside the constructor is the constructor that was actually invoked with `new`, and a derived class with no explicit constructor forwards it through. Options 1 and 2 differ in a detail worth knowing: an assignment in the constructor creates an *own, enumerable* property on every instance, so `name` shows up in `Object.keys(err)` and in a `JSON.stringify` of the error, whereas the prototype assignment keeps instances clean (though a `for...in` still walks up and sees it). Built-in errors keep `name` non-enumerable on the prototype; the prototype form is the closer match. ## Carrying data, not just a message The real value of a custom error class is the structured payload. A message is for humans; the fields are for code. Attach the identifiers a caller needs to react — the failing field, an operation id, a stable string `code` — and keep them own enumerable properties so they survive being logged. ```js class HttpError extends Error { constructor(status, url) { super(`Request to ${url} failed with ${status}`); this.name = 'HttpError'; this.status = status; this.url = url; } } ``` Keep the constructor cheap and total: it should not perform I/O, and it must not throw, because it runs on the failure path where things are already going wrong. ## The serialization surprise `JSON.stringify(new Error('boom'))` produces `"{}"`. `message` is an own property but **non-enumerable**, and `name` is not an own property at all, so the default serializer finds nothing. Fields you assign yourself *are* enumerable and do survive, which means a custom error partially serializes while a built-in one vanishes. If errors travel as JSON, define an explicit shape rather than relying on `stringify`. ## Why `instanceof` can break in a downlevelled build When a toolchain compiles the class down to ES5 function syntax, it cannot use `super` — it calls `Error.call(this, message)`. The built-in `Error` constructor called that way ignores the passed `this` and returns a fresh object, so the instance under construction never gets the right prototype and `err instanceof ValidationError` can come back `false`. The standard repair inside the constructor is: ```js Object.setPrototypeOf(this, new.target.prototype); ``` This is unnecessary — and harmless — when the class runs as a native class, which is the normal case on an ES2015+ target. Knowing why the line exists is the point: it tells you that error-class identity is a build-target concern, not only a source-code one.