All 15 Error Handling questions
More in Error Handling
What is the difference between throwing an error synchronously and calling a callback with an error as its first argument in Node.js? How would you create and use custom Error subclasses in a Node.js application to represent different categories of application-specific errors? Why doesn't Express automatically catch errors thrown inside an async route handler in versions prior to Express 5, and how do you work around this? How do you correctly propagate and handle errors from a Node.js stream, given that stream errors aren't caught by a surrounding try/catch? What is the try/catch/finally pattern's 'finally' block used for, and how does it behave with async/await? What is the risk of exposing a raw error's stack trace in an API response, and how do you prevent it while still logging full details server-side? What is the difference between a validation error and a business-logic error, and how might a Node.js application handle each differently? How would you implement a global 'not found' (404) handler in Express for any route that doesn't match a defined endpoint? What is a centralized error-handling middleware pattern in Express, and what advantages does it provide over handling errors in each individual route? What is the difference between a 4xx and 5xx HTTP status code from an error-handling perspective, and how should a Node.js API decide which to return?
Advertisement
Node.js › Error Handling

What is the difference between operational errors and programmer errors in Node.js, and why does this distinction matter?

Beginner

Answer

Operational errors are expected, recoverable failures that arise from the runtime environment or external conditions (a failed network request, invalid user input, a database connection drop) -- these should be handled gracefully, typically returning an appropriate error response. Programmer errors are actual bugs in the code (calling a method on undefined, a typo, incorrect logic) that indicate the program is in an unknown, potentially corrupted state -- these generally should NOT be caught and silently continued from, since doing so risks the application continuing in an inconsistent state; the safer response is usually to let the process crash and restart cleanly.
// Operational error: expected, handle gracefully
try {
  const user = await db.users.findById(id);
} catch (err) {
  if (err.code === 'CONNECTION_TIMEOUT') return res.status(503).json({ error: 'Service temporarily unavailable' });
}

// Programmer error: a bug, shouldn't be silently swallowed
// TypeError: Cannot read properties of undefined -- indicates broken code, not a recoverable condition
Real-world example A team's error-handling strategy treats a failed payment-gateway API call (operational) by retrying and showing the user a friendly error message, while a TypeError from accessing a property on an unexpectedly undefined object (programmer error) is allowed to crash the process, triggering an automatic restart and an alert to fix the actual bug.

Common follow-ups: Why is it dangerous to catch and ignore a programmer error like a TypeError rather than letting the process crash?;How do custom error classes help distinguish operational from programmer errors at the point they're caught?

Advanced Node.js;Debugging & Diagnostics
All 15 Error Handling questions