errors-reliabilityAnswer last reviewed July 2026

Say a promise rejects somewhere and nothing ever handles it. What does Node do, and what should your process do about it?

A strong answer nails the exact crash semantics of unhandled rejections and uncaught exceptions, then argues crash versus continue from state integrity

What an AI-prepared candidate might say

So if a promise rejects and nothing handles it, older versions of Node just printed a deprecation warning, but modern Node treats it as fatal and crashes the process. Which is why you always attach a .catch or wrap your await in a try/catch. Most teams I've seen also register process.on('unhandledRejection') and process.on('uncaughtException') handlers so they can log the error and report it to monitoring before anything gets lost. The usual advice is basically log it with the stack trace, send it to your error tracker, and if it looks serious, shut down gracefully, because one bad request shouldn't take down the whole service. And your process manager or orchestrator restarts the app for you anyway, so really the main job is making sure every rejection either gets handled locally or gets caught by a global handler somewhere.

Senior
Locked

Pins down exactly when the unhandledRejection event fires, what each --unhandled-rejections mode changes, and why just registering the handler alters crash behavior.

Unlock the depth
Staff
Locked

What you can still safely run in the last hundred milliseconds before exit, and how to keep one poison input from crash-looping an entire fleet.

Unlock the depth
Follow-up chain
Say a promise rejects somewhere and nothing ever handles it. What does Node do, and what should your process do about it? | NodeBook