Lesson 15 of 80

Error Boundaries

Q: What are error boundaries, what do they catch, and what do they explicitly not catch?

A strong answer covers: A class component using getDerivedStateFromError/componentDidCatch to catch render-phase errors in its children and show a fallback UI instead of crashing the whole app; Does NOT catch: errors in event handlers, errors in async callbacks, or errors in the boundary's own render; Requires a class component — no hook equivalent exists.

A render error in one component normally crashes the whole app — an error boundary is the one thing that can catch it and show a fallback instead, and it still requires a class component.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Can you build an error boundary as a function component using hooks?

No — there's no hook equivalent of getDerivedStateFromError/componentDidCatch yetYes, using useErrorBoundary from React's hook APIYes, by wrapping the component in a try/catch inside its function body

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Error Boundaries

What interviewers actually ask about this, and what a strong answer has to cover.

What are error boundaries, what do they catch, and what do they explicitly not catch?

A strong answer covers

A class component using getDerivedStateFromError/componentDidCatch to catch render-phase errors in its children and show a fallback UI instead of crashing the whole app
Does NOT catch: errors in event handlers, errors in async callbacks, or errors in the boundary's own render
Requires a class component — no hook equivalent exists

Likely follow-ups

How would you handle an error thrown inside an onClick handler, given a boundary won't catch it?
Where would you place error boundaries in a real app — one global boundary, or several scoped ones? Why?
What's the difference between getDerivedStateFromError and componentDidCatch — why are there two methods?

Practice these with the AI interviewer →

The plain-language idea

By default, an uncaught error thrown during render anywhere in the tree unmounts the entire app — React deliberately doesn't leave a half-broken UI on screen. An error boundary is a component that catches render errors in its children and shows a fallback UI instead of taking down everything above it.

class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError(error) {
    return { hasError: true };            // triggers the fallback render
  }

  componentDidCatch(error, info) {
    logErrorToService(error, info);       // side effect: reporting
  }

  render() {
    if (this.state.hasError) return <h2>Something went wrong.</h2>;
    return this.props.children;
  }
}

<ErrorBoundary>
  <WidgetThatMightThrow />
</ErrorBoundary>

Error boundaries: render-phase onlyStep 1 of 4

ErrorBoundary wraps Widget. Normal rendering — children render straight through, untouched.

What error boundaries don't catch

Watch out

Errors in event handlers aren't caught. A throw inside an onClick is a normal JS runtime error, not a render error — handle those with a regular try/catch inside the handler itself.
Errors in async code (a setTimeout callback, a .then()) aren't caught either — same reason: they happen outside React's render call stack, where the boundary isn't watching.
A boundary doesn't catch its own errors — if the boundary component's own render throws, the error propagates to the nearest boundary above it, not back into itself.
You can nest multiple boundaries to isolate failures — a boundary around one risky widget keeps the rest of the page alive even if that widget crashes.

Why this matters in interviews

"What does an error boundary catch, and what does it not catch?" is the real question — knowing the boundary exists is the easy part; knowing it's scoped to render-phase errors specifically (not events, not async) is what shows genuine hands-on understanding.