How do you handle errors in Node.js applications? | Interview Question

Q: How do you handle errors in Node.js applications?

**Target Audience:** Engineers preparing for Node.js interviews — assumes basic Express and Promise familiarity. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The Express behavior below was **actually executed** against a real Express 4.22.2 server, including a real crash, not described from documentation. ## 1. Why This Even Matters — A Story First A building's fire-alarm system automatically notifies the fire department for smoke detected anywhere in the building — except, in an older wing built to an outdated code, the automatic notification was never wired into one specific hallway's detectors. Those detectors still sound locally, but nobody outside that hallway is automatically told. Anyone relying on "the alarm system handles this" without knowing about that one wing is in for a bad surprise exactly when it matters most. Express 4's async route handlers are that unwired hall

The problem

Question presented to candidate: "An async Express route handler throws an error with no try/catch around it. What happens to that request, and does your answer change between Express 4 and Express 5?"

What a strong answer should cover:

Node.js error handling is not one mechanism — it differs by context: synchronous code uses try/catch; callback-style async code uses the error-first (err, result) convention; Promise-based/async code uses try/catch around await, or .catch().
📌 A version-specific, verifiable gap: in Express 4, a synchronous throw inside a route handler is automatically caught and routed to centralized error-handling middleware — but an async handler that throws (or rejects) with no manual next(err) call is not caught automatically; it crashes the process as an uncaught exception. Express 5 fixes this specific gap, automatically forwarding a rejected promise from an async handler to next().
Centralized error-handling middleware in Express is a 4-argument function (err, req, res, next) — Express recognizes this specific arity and routes errors to it, distinct from ordinary 3-argument middleware.
The operational vs. programmer error distinction (covered fully in its own dedicated question) determines the right response once an error is caught: an operational error should be handled and answered with an appropriate status code; a programmer error/bug should generally be logged and allowed to crash the process for a supervisor to restart, rather than papered over.
uncaughtException/unhandledRejection handlers at the process level are a last-resort safety net — logging and exiting — not a substitute for handling errors correctly at the point they actually occur.
A precise answer names the practical mitigation for the Express-4 async gap specifically: wrap every async handler in a small utility (a manual try/catch calling next(e), or a wrapper like express-async-handler) until/unless the codebase is on Express 5.

Clarifying questions expected:

"Which Express major version, or a different framework entirely?" — the async-handler auto-catch behavior is genuinely version-dependent, verified above.
"Is the concern about a specific caught error's response, or the broader process-level safety net?" — these are different layers of the same overall topic.

Code / implementation expected: Yes — actually demonstrating the Express 4 async-handler gap (a real crash) versus the manual-next(e) fix is the concrete, convincing part of the answer.

error handling
asynchronous
promises
best practices

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js interviews — assumes basic Express and Promise familiarity. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The Express behavior below was actually executed against a real Express 4.22.2 server, including a real crash, not described from documentation.

1. Why This Even Matters — A Story First

A building's fire-alarm system automatically notifies the fire department for smoke detected anywhere in the building — except, in an older wing built to an outdated code, the automatic notification was never wired into one specific hallway's detectors. Those detectors still sound locally, but nobody outside that hallway is automatically told. Anyone relying on "the alarm system handles this" without knowing about that one wing is in for a bad surpris

The solution is hidden so you can try first

7 min read · 9 sections

Read the code

JavaScriptA real Express 4 server: sync throw auto-caught, async+next(e) forwarded correctly, unhandled async throw crashes the process

const express = require("express");
const app = express();

app.get("/sync-throw", (req, res) => { throw new Error("sync error"); });

app.get("/async-throw-manual", async (req, res, next) => {
  try { throw new Error("async error"); } catch (e) { next(e); }
});

app.get("/async-unhandled", async (req, res) => {
  throw new Error("unhandled async error"); // Express 4: NOT caught, crashes the process
});

app.use((err, req, res, next) => { // 4 args = error middleware, recognized by arity
  res.status(500).json({ error: err.message });
});

// sync-throw               -> 500 { error: "sync error" }
// async-throw-manual       -> 500 { error: "async error" }
// async-unhandled          -> process CRASHES (Express 4 has no auto-catch here)

// The fix, until on Express 5:
const wrap = (fn) => (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next);
app.get("/safe", wrap(async (req, res) => { throw new Error("now correctly forwarded"); }));

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.