Error propagation

Let errors travel up to a place that knows what to do with them, usually one error handler per server. Wrap low-level errors with context, keep the original as the cause, and never swallow one silently.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain where errors should be caught in a server
Wrap a low-level error with context and keep the cause
Spot the catch that returns a generic 500 and strips the real error

In practice

A few lines that show Error propagation doing its job.

JavaScript

class NotFound extends Error {
  constructor(what) { super(what + " not found"); this.status = 404; }
}

app.get("/orders/:id", async (req) => {
  const order = await orders.find(req.params.id);
  if (!order) throw new NotFound("order " + req.params.id);
  return order;
});

app.setErrorHandler((error, req, reply) => {
  req.log.error({ err: error });
  reply.code(error.status ?? 500).send({ error: error.status ? error.message : "Internal error" });
});

The common mistake

Watch for

Catching an error inside a route to return a generic 500, which strips the status and message the error carried. Throw it and let the central handler map it.

What to know first

Your roadmap puts these before Error propagation, unless you already know them.

How it stays learned

Once a session shows you understand Error propagation, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Previous in the module← Promises and async/await

Next in the moduleConcurrency limits →