Error Handling

Two categories, two tools. Frontend errors split cleanly. Rendering errors — an exception thrown during render, in a lifecycle method, or in a child's constructor — are caught by an Error Boundary. Everything else — event handlers, async code, and data fetching — is caught by ordinary try/catch (or a promise .catch). Using the wrong tool is the #1 error-handling mistake: boundaries do NOT catch async or network errors.

Network vs application errors. A network error means the request never got a response — the server is down, the connection dropped, a timeout fired, or CORS blocked it (error.request in Axios, no error.response). An application error means the server responded but with a failure status — 400/401/403/404/422/500 (error.response present with a status). They need different UX: network errors say 'check your connection / retrying', application errors show a specific message tied to the status.

Error boundaries — the render-path safety net. Boundaries must be class components: they implement static getDerivedStateFromError to switch to a fallback UI and componentDidCatch to log the error (e.g. to Sentry). Wrap sections of the app so a crash in one widget shows a fallback instead of unmounting the whole tree (a blank white screen). Place several small boundaries around independent regions rather than one giant boundary at the root.

What boundaries deliberately miss. They do not catch errors in event handlers, setTimeout/promise callbacks, data fetching, server-side rendering, or errors thrown in the boundary itself — none of those happen during rendering. In modern apps you often use the community react-error-boundary package for a hook-friendly API (useErrorBoundary, a FallbackComponent, and an onReset), but under the hood it's still a class.

Status-aware API handling. For the network path, a reusable safeApiCall/handleError inspects the error with axios.isAxiosError and branches on error.response?.status: 404 → 'not found', 422 → surface field validation, 401 → refresh/redirect, 429 → back off, 5xx → 'server error, try again', and no response → 'network error'. Centralizing this keeps components focused on rendering rather than error plumbing.

Retries and backoff for transient errors. Some failures are transient (5xx, 429, dropped connections) and worth retrying; deterministic ones (400, 422) are not — retrying just wastes time and can annoy the user. Retry up to a small max with exponential backoff (base * 2^attempt) plus jitter to avoid a thundering herd, and honor a Retry-After header on 429. Data libraries like React Query do this for you (retry, retryDelay), which is usually where retry logic belongs.

Graceful user feedback. Every failure needs a human-readable outcome. Use toasts for transient/recoverable errors, inline field errors for 422 validation, a fallback region (from the error boundary) for a crashed widget, and a full-page error with a retry button for a fatal load failure. Never show a raw stack trace or a bare 'Error' — and never silently swallow an error, which hides bugs from both users and you.

Loading, empty, error, and success are four states. A robust data component always models all four, not just success. React Query gives you isLoading, isError, error, and data; render a spinner, an error state with retry, an empty state, and the data respectively. 'It works on my machine' bugs are usually an unmodeled error or empty state.

Optimistic updates and rollback. For snappy UX you can apply a mutation to the UI immediately and roll back if the request fails. This is powerful but error-prone: you must keep the previous state and restore it in the error handler (React Query's onMutate/onError/onSettled formalize this). If you can't cleanly roll back, prefer a pending state instead.

Global handlers catch what you missed. Register window.addEventListener('error', ...) and window.addEventListener('unhandledrejection', ...) to catch stray errors and rejected promises that no local handler caught, and report them to monitoring. This is a safety net, not a substitute for local handling — but it surfaces the errors you didn't anticipate.

Monitoring in production. Log caught errors to a service (Sentry, Datadog) from componentDidCatch and your global handlers, with context (user id, route, release). This is how you learn about crashes real users hit — the console is invisible in production. Attach a release/version so you can tell which deploy introduced a regression.

The mental model (memorise this). Two paths, two tools: error boundaries wrap the render path so a crash degrades to a fallback, and try/catch handles the async/network path. Distinguish network (no response) from application (bad status) errors, branch on status for the right message, retry only transient failures with backoff, give the user a real state (loading/empty/error/success) for every fetch, and always log to monitoring so production failures aren't invisible.