7 Errors

JavaScript errors are presented as a simple feature, but in practice they are shaped by implementation details, runtime conventions, and a long history of engine-specific behavior. The chapter explains that errors are useful for two very different purposes: applications need concise signals for recovery, while developers need rich diagnostic detail for debugging. Because those goals demand different information, error handling in JavaScript becomes a balance between preserving enough context to understand failures and keeping the runtime cost of that context under control.

The text distinguishes between ordinary thrown values and standardized Error objects, then shows how modern error features improve both recovery and debugging. Native error types like TypeError and RangeError mainly describe language-rule violations, while newer additions such as AggregateError, SuppressedError, and the cause property preserve more meaningful failure chains. The chapter also highlights host-specific systems such as DOMException and Node.js error codes, which give machines stable identifiers for recovery while leaving human-readable messages for developers.

A major theme is that stack traces are invaluable but expensive: they consume memory, take time to capture, and become even costlier when serialized or repeated at scale. Error propagation is shown as a control-flow process where throw moves an error up the call stack until a matching handler is found, so placement of handlers matters. Best results come from catching errors at semantic boundaries such as transactions, API calls, or resource cleanup, while global handlers remain only a last-resort safety net. The chapter ends by stressing that asynchronous boundaries break ordinary try-catch behavior, so error handling must adapt when work is scheduled to run later.

• JavaScript allows throwing any value, but Error objects with stack traces are the standard convention for providing both recovery information and debugging context.
• Native error types like TypeError and RangeError describe language violations but provide no recovery guidance. Modern additions like AggregateError and DOMException types address specific failure scenarios more meaningfully.
• The cause property enables error wrapping at boundaries, preserving complete debugging context while presenting clean recovery information at each layer.
• Node.js error codes separate machine-readable recovery mechanisms from human-readable debugging messages, preventing brittle error message parsing.
• Stack traces capture the function call chain for debugging but carry significant memory and performance costs. Engines optimize through lazy serialization and configurable depth limits.
• Error propagation through try-catch works by unwinding the call stack frame by frame until a handler is found or the application crashes.
• Place catch handlers at semantic boundaries—transaction, API, resource, or user operation boundaries—where you have context for both recovery decisions and debugging detail.
• Finally blocks guarantee cleanup execution but can suppress or replace errors, breaking both recovery and debugging if return statements or throws are used carelessly.
• Asynchronous operations like setTimeout break the call stack, preventing try-catch from catching errors and leaving incomplete stack traces that lack scheduling context.
• Global error handlers (window.error, process.uncaughtException) catch errors that escape all try-catch handlers but are too far from error context for effective recovery or debugging.
• When errors regularly reach global handlers, it signals missing error handling at proper boundaries. Global handlers should be a safety net, not a primary strategy.
• The async boundary problem requires different error handling mechanisms explored in Chapter 8, where Promises and async/await provide error propagation that works across async operations.

FAQ