Question 1

How do try, catch, and finally work in JavaScript?

Accepted Answer

try runs code that may throw; catch handles the error; finally runs for cleanup whether the try succeeded or failed. When an exception is thrown, the stack unwinds to the nearest catch. finally executes before control leaves the construct — even on return inside try/catch. If finally throws, it can mask the original error. catch bindings are block-scoped. Prefer catching only where you can recover or add context; otherwise let errors bubble to a boundary. Works with await inside async functions to catch promise rejections.

Question 2

What built-in Error types should you know, and when do you create custom errors?

Accepted Answer

Know Error, TypeError, ReferenceError, RangeError, SyntaxError; create custom subclasses for domain-specific failures with stable codes. Built-ins communicate programmer mistakes vs invalid values. Custom errors (class ValidationError extends Error) enable instanceof checks and structured fields (code, details). Set name and use super(message); in older targets, fix prototype chain. Prefer error causes ({ cause }) to wrap lower-level failures without losing stacks. Don't over-hierarchize — a few meaningful types beat dozens.

Question 3

Why doesn't a surrounding try/catch always catch errors from async code, and how do you fix that?

Accepted Answer

try/catch only catches synchronous throws / awaited rejections in that block; floating promises and callback errors escape unless handled. Calling an async function without await/.catch schedules work that rejects later — outside the original try. Event handlers and setTimeout callbacks need their own handling. Patterns: always await or attach catch; use global unhandledrejection as a last-resort logger; in UI frameworks use error boundaries for render errors (note: they don't catch all async). Wrap async event handlers. Lint floating promises.

Question 4

How do you distinguish operational errors from programmer errors in a JS service, and how should each be handled?

Accepted Answer

Operational errors are expected runtime failures (network, validation); programmer errors are bugs. Handle operational, crash/alert on programmer where appropriate. In Node-ish thinking: operational — retryable HTTP failures, invalid user input — return structured errors to clients. Programmer — undefined is not a function — fail fast, log loudly, fix code. Catching programmer errors and continuing can corrupt state. In browsers, show user-friendly messages for operational issues and report bugs to monitoring. Validate inputs at boundaries so core logic can assert invariants. This taxonomy guides whether to catch or throw.

Question 5

How do you preserve context when wrapping errors across layers (e.g. UI ← API client ← fetch)?

Accepted Answer

Wrap with new Error(msg, { cause: original }) or custom errors carrying codes; log with full cause chain without leaking sensitive details to users. Each layer should add domain context ('Failed to load invoice 123') while keeping the underlying cause for diagnostics. ES2022 cause chains support this. Map low-level failures to stable app error codes for UI. Avoid double-logging at every layer. Sanitize messages shown to users. In TypeScript, typed error results are an alternative to exceptions for expected failures — pick a convention per layer. Include request IDs for correlation.

Question 6

What global error hooks exist in browsers/Node, and what should they do vs not do?

Accepted Answer

Browsers: window.onerror, unhandledrejection. Node: uncaughtException, unhandledRejection. Use for logging/telemetry; don't use as normal control flow. Global handlers are safety nets for unexpected failures — report to Sentry/etc., show a generic recovery UI, and in Node often exit on uncaughtException because state may be corrupt. Prefer local handling for expected paths. Ensure handlers themselves don't throw. Filter noisy aborted fetches. Include release/version metadata. For SPAs, pair with route-level boundaries. Document that covering every error globally does not replace thoughtful API design.

Question 7

Design an error-handling strategy for a multi-team JS platform (shared client SDK, web apps, and Node workers).

Accepted Answer

Standardize error shapes/codes, layer-specific handling rules, telemetry taxonomy, and privacy redaction; enforce via shared libraries and lint. Define a shared AppError with code, status, retryable, cause, and safe userMessage. Map HTTP and domain failures once in the SDK. Apps: translate codes to UX; never parse free-text. Workers: retry policies based on retryable, dead-letter after N. Telemetry: severity, code, fingerprinting, PII scrubbing. Ban empty catches via lint. Provide playbooks for incidents. Version error contracts. Decide exceptions vs Result types per language boundary (TS). Leadership includes training and review checklists so teams don't invent incompatible schemes.

Error Handling JavaScript Interview Questions

Other JavaScript interview topics