JavaScript Error Types & Custom Errors
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list ESLint and TypeScript as the tools. ESLint can flag bare catch(e) with no type discrimination and throwing string literals, but these rules are not default — they require specific plugins or rules (e.g. no-throw-literal). TypeScript can catch some cases but not runtime error-type narrowing. This places it at d5 rather than d3 (not a default linter catch) or d7 (automated tooling does exist).
Closest to 'simple parameterised fix' (e3). The quick_fix is to use custom error classes extending Error with meaningful name and code properties, and to catch specific types. This is a small, pattern-based refactor — replacing generic catch blocks and string throws with proper class definitions — contained within one component or file at a time, not a cross-cutting architectural change.
Closest to 'localised tax' (b3). The applies_to covers web and cli contexts broadly, but the impact is scoped to error-handling code paths. Misuse of error types doesn't poison the broader architecture — it affects catch blocks and error propagation locally. Each fix is contained to the module or component that handles a specific error flow, so the structural weight is moderate but not system-wide.
Closest to 'serious trap' (t7). The misconception is explicit: developers believe catch(e) is safe, but broad catches silently swallow unexpected bugs. This contradicts patterns from other languages (e.g. Java/C# where typed catch clauses are enforced), and the 'obvious' pattern in JavaScript — a plain catch — is almost always the wrong approach for robust error handling. This is a well-documented but frequently violated gotcha that contradicts how similar constructs behave in typed languages.
Also Known As
TL;DR
Explanation
Built-in errors: Error (base), TypeError (wrong type), RangeError (value out of range), ReferenceError (undefined variable), SyntaxError (invalid syntax), URIError, EvalError. Custom errors extend Error: class ValidationError extends Error {}. Key gotcha: Error.prototype.stack and instanceof checks can break across browser contexts and iframes. For custom errors, always set this.name = 'ValidationError' explicitly. Use instanceof for catching specific error types in catch blocks.
Common Misconception
Why It Matters
Common Mistakes
- Not setting this.name in custom errors — error.name stays 'Error' instead of 'ValidationError'.
- Not calling super(message) in custom error constructor — error.message is empty.
- Catching all errors and swallowing unexpected ones — only catch errors you can handle.
- Throwing strings instead of Error objects — strings have no stack trace.
Code Examples
// Throwing strings — no stack trace:
throw 'User not found'; // Untyped, no stack
// Catching everything — hides bugs:
try {
processPayment();
} catch (e) {
console.log('Error'); // TypeError from programming bug silently swallowed
}// Custom error hierarchy:
class AppError extends Error {
constructor(message: string, public readonly code: string) {
super(message);
this.name = this.constructor.name; // 'AppError'
}
}
class ValidationError extends AppError {}
class NotFoundError extends AppError {}
// Specific handling:
try {
await processPayment(order);
} catch (e) {
if (e instanceof ValidationError) showUserError(e.message);
else if (e instanceof NetworkError) scheduleRetry();
else throw e; // Rethrow unknown errors — don't swallow
}