What is error handling across the stack?
It is the full path of a failure: something goes wrong on the server, the error is shaped and sent with the right status, the client receives and interprets it, and the UI shows the user something useful. Owning both ends means designing this whole path, not just one side.
Why it matters
Errors are inevitable, and how an app handles them is a big part of how it feels. A failure that surfaces as a blank screen or a cryptic message erodes trust. A consistent error contract from server to UI lets you handle failures gracefully everywhere, which is a hallmark of a polished full-stack app.
What to learn
- A consistent server error shape
- Mapping errors to HTTP status codes
- Distinguishing expected errors from unexpected crashes
- Propagating errors through tRPC or fetch to the client
- Client error boundaries and fallback UI
- User-friendly messages versus internal detail
- Logging the real error server-side
Common pitfall
Leaking raw server errors and stack traces to the client. It is a security risk — it exposes internals — and a terrible user experience. Return a clean, structured error with a safe message and the right status to the client, while logging the full detail server-side for yourself.
Resources
Primary (free):
- tRPC — Error handling · docs
- React — Error boundaries · docs
- MDN — HTTP status codes · docs
Practice
Design an error path end to end: throw a known error on the server with a status and safe message, propagate it to the client, and render a friendly fallback in an error boundary — while logging the full error server-side. Trigger an unexpected crash and confirm no stack trace reaches the client. Done when failures degrade gracefully.
Outcomes
- Define a consistent server error shape and status mapping.
- Propagate errors cleanly to the client.
- Show friendly fallback UI with error boundaries.
- Never leak stack traces or internals to the client.