What's the difference between operational and programmer errors?

Answer: This distinction (popularized by Joyent's Node error-handling guide) drives how you should respond to an error.

Operational errors — runtime conditions a correct program will encounter:

• Failed DNS lookup, connection reset, request timeout.
• Invalid user input, 404 from an upstream API, disk full, file not found.
• These are expected. Handle them: validate, retry with backoff, return a proper error response, use a fallback.

try {
  const res = await fetch(url);
  if (!res.ok) return reply(res.status, 'Upstream error');
} catch (err) {
  // network timeout etc. — operational
  return reply(503, 'Service unavailable');
}

Programmer errors — bugs in your code:

• undefined is not a function, reading a property of null, passing the wrong type, forgetting to await.
• You cannot sensibly recover from these at runtime because the program's assumptions are broken. The right response is to let it crash, log with a stack trace, and fix the code.

Why it matters:

• Wrapping everything in try/catch and swallowing errors hides programmer bugs and leaves the process in a bad state.
• Retrying a programmer error just repeats the bug.

Practical guidance:

• Handle operational errors explicitly and locally.
• Let programmer errors bubble to the top; use uncaughtException/unhandledRejection only to log and restart.
• Custom error classes (below) help you distinguish the two (e.g., an isOperational flag).