Error Boundaries

An error boundary is a class component that catches render-time errors in its children and shows a fallback UI instead of crashing the whole app to a blank screen. It's React's try/catch for the component tree. By the end you'll build one, know exactly what it can and can't catch, and place boundaries to keep your app resilient.

Learn Error Boundaries in our free React course — a beginner-friendly interactive lesson with runnable examples, a practice exercise and a quick recall.

Part of the free React course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

1️⃣ Why Boundaries Exist

If any component throws during render and nothing catches it, React unmounts the entire tree — the user sees a blank white page. An error boundary catches that error, shows a friendly fallback, and keeps the rest of the app running. It's defined as a class with two special methods.

The demo models that try/catch behavior — a healthy child renders, a throwing child falls back:

Your turn — complete the catch so a crashing child returns the fallback:

2️⃣ Using a Boundary

Wrap any part of your tree that might fail. Everything inside is protected; if it throws during render, the boundary's fallback appears in its place while the rest of the page stays interactive.

Crucially, boundaries only catch render-phase errors in children. They do not catch errors in event handlers, in setTimeout /promises, or thrown by the boundary itself — those still need a regular try/catch .

3️⃣ Granular Boundaries Isolate Failures

A single top-level boundary is a good safety net, but a crash there still replaces the whole screen. Place smaller boundaries around independent widgets so one failure only blanks that widget — the rest of the dashboard keeps working.

The demo models that isolation — one broken widget falls back while its neighbors render fine:

These lines define an error boundary class. Put them in a correct order:

1) A button's onClick handler throws. Does the error boundary catch it?

No. Boundaries catch only render-phase errors. Event handler errors need a regular try/catch .

2) Which method flips state to show the fallback, and which is for side effects like logging?

static getDerivedStateFromError updates state; componentDidCatch handles side effects (logging).

3) Why use several small boundaries instead of one at the root?

To isolate failures — a crash in one widget falls back locally while the rest of the UI stays alive.

📋 Quick Reference

Model a boundary around three widgets where the middle one throws. Render each through the boundary and log the lines. The healthy widgets should still appear — predict the output first.

Practice quiz

What is an error boundary in React?

  • A hook that catches errors
  • A try/catch around fetch calls
  • A class component that catches render-time errors in its children and shows a fallback UI
  • A Suspense boundary

Answer: A class component that catches render-time errors in its children and shows a fallback UI. An error boundary is a class component that catches errors thrown by children during rendering and shows a fallback.

Why must an error boundary be a class component?

  • The catching lifecycle methods exist only on class components
  • Classes render faster
  • Function components can't have state
  • It is just a convention

Answer: The catching lifecycle methods exist only on class components. getDerivedStateFromError and componentDidCatch are class-only lifecycle methods; there's no hook equivalent yet.

Which method updates state to show the fallback on the next render?

  • componentDidCatch
  • componentDidMount
  • render
  • static getDerivedStateFromError

Answer: static getDerivedStateFromError. static getDerivedStateFromError(error) returns new state (e.g. { hasError: true }) to render the fallback.

Which method is intended for side effects like logging the error?

  • getDerivedStateFromError
  • componentDidCatch
  • render
  • constructor

Answer: componentDidCatch. componentDidCatch(error, info) handles side effects such as logging to a monitoring service.

Does an error boundary catch errors thrown inside an event handler?

  • No — it catches only render-phase errors in children
  • Yes, always
  • Only in production
  • Only for onClick

Answer: No — it catches only render-phase errors in children. Boundaries catch render-phase errors. Event handler errors need ordinary try/catch.

Which of these does an error boundary NOT catch?

  • A render error in a child component
  • An error during a child's render method
  • An error in async code like setTimeout or a promise
  • A throw in a child's JSX expression

Answer: An error in async code like setTimeout or a promise. Boundaries don't catch errors in event handlers, async code, SSR, or the boundary itself.

What happens by default if a component throws during render and nothing catches it?

  • React shows a red box and continues
  • React unmounts the entire tree — the user sees a blank screen
  • Only that component is hidden
  • Nothing visible changes

Answer: React unmounts the entire tree — the user sees a blank screen. An uncaught render error unmounts the whole tree, leaving a blank page — which boundaries prevent.

Why place several granular boundaries instead of one at the root?

  • It is required by React
  • To make the bundle smaller
  • To avoid using classes
  • To isolate failures so one widget's crash doesn't blank the whole app

Answer: To isolate failures so one widget's crash doesn't blank the whole app. Granular boundaries fall back locally, keeping the rest of the UI alive when one section crashes.

What should getDerivedStateFromError return?

  • The error object
  • New state, e.g. { hasError: true }
  • A fallback element
  • undefined

Answer: New state, e.g. { hasError: true }. It returns a state update (like { hasError: true }) so render can show the fallback.

An error boundary's hasError stays true and never recovers. What's a fix?

  • Nothing can reset it
  • Delete componentDidCatch
  • Provide a retry that resets state or remount via a key
  • Make it a function component

Answer: Provide a retry that resets state or remount via a key. Offer a retry that resets hasError, or remount the subtree via a changing key, to recover.