Operational versus programmer errors in Node.js

WHAT THIS TESTS Whether you understand that not all errors are equal and that recovery policy depends on whether process state can be trusted afterward.

A GOOD ANSWER COVERS Operational errors are expected conditions that a correct program will still encounter: invalid user input, a record not found, a failed network or database call, a rate limit hit. They are part of normal operation, so you handle them locally, return an appropriate HTTP status to the client, and keep serving other requests. Programmer errors are bugs in your code: reading a property of undefined, passing the wrong type, a typo. After such a bug the process may be in an inconsistent state, holding half-updated data or leaked resources, so it cannot be trusted to continue safely. The robust policy is to log the full error, fire alerts, finish in-flight requests if possible, then exit and let a process manager (PM2, systemd, Kubernetes) restart a clean instance.

COMMON WRONG ANSWERS Wrapping everything in try/catch and resuming regardless, crashing the server on every operational error, or treating an undefined-access bug as something to recover from in place.

LIKELY FOLLOW-UPS How this maps to uncaughtException handling, the isOperational flag, why restarting is safer than resuming after a bug, and zero-downtime restarts.

ONE CONCRETE EXAMPLE A POST with a duplicate email is an operational error: catch it, return 409 Conflict, keep running. But if a handler calls user.profile.name where profile is undefined, that TypeError is a programmer error; the safest response is to log it, return a generic 500, and let the supervisor restart the process rather than risk serving further requests from a possibly corrupted state.