What types of errors are there?
By FrontendPro Editorial Team Updated 9/26/2026
Answer
Two useful ways to group them: by when they happen, and by which built-in type is thrown.
By when
- Syntax errors — the file cannot be parsed, so nothing in it runs. A missing bracket takes the whole script down.
- Runtime errors — the code is valid but fails while executing: reading a property of
undefined, calling something that is not a function. - Logic errors — it runs without complaint and produces the wrong answer. No engine can catch these; only tests and review can.
The built-in error types
null.foo; // TypeError — wrong type for the operation
notDefined; // ReferenceError — no such binding
JSON.parse("{"); // SyntaxError — at parse time
arr.length = -1; // RangeError — value outside the allowed range
decodeURIComponent("%"); // URIError
TypeError and ReferenceError cover the large majority of what you will see. Knowing which one appeared is diagnostic: ReferenceError means the name does not exist at all — a typo, a missing import, or a temporal dead zone. TypeError means the name exists but holds something unsuitable.
Reading an error
err.name // "TypeError"
err.message // "Cannot read properties of undefined (reading 'id')"
err.stack // where it happened
err.cause // the original error, if it was wrapped
The modern message tells you both the operation and the property, which usually points straight at the line.
Your own types
Extend Error so callers can branch on the failure rather than parse strings:
class ValidationError extends Error {
constructor(field, msg) { super(msg); this.name = "ValidationError"; this.field = field; }
}
Always throw Error objects. throw "oops" produces a value with no stack trace, which most logging and monitoring tools cannot use.
