Interview answer drill

Use this React interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow 30-day foundations study plan Practice more React interview questions

What problem do Error Boundaries solve? What don’t they catch?Frontend interview answer

HighIntermediateReact

By FrontendAtlas Team · Updated Apr 4, 2026

Interview focus

This React interview question tests whether you can explain React Error Boundaries in production: render-crash isolation, fallback UI, and what they do not catch, connect it to production trade-offs, and handle common follow-up questions.

React Error Boundaries in production: render-crash isolation, fallback UI, and what they do not catch explanation without falling back to memorized docs wording
Error Handling and Components reasoning, edge cases, and production failure modes
How you would answer the most likely React interview follow-up

Practice more React interview questions

Interview quick answer

Explain Error Boundaries through render-crash isolation, fallback UI, monitoring, and the common production mistake of expecting them to catch event-handler, async, or SSR errors.

Full interview answer

Production bug to isolate

Error Boundaries exist to stop one crashing subtree from taking down the entire visible UI. The beyond-basics part is scope: they are great for render-time crashes and fallback UX, but a common production mistake is assuming they also catch event-handler failures, async errors, or SSR problems. They isolate the render tree, not every possible runtime exception.

What they are (mental model)

An Error Boundary is like a seatbelt for a part of your component tree.

Without it: one render error can crash the whole render path.
With it: React catches the error and renders a fallback for that subtree.

What Error Boundaries catch	Where the error happens	Why it matters
Errors during rendering	While React is computing the UI output	Prevents blank screens / app crashes
Errors in lifecycle methods (class components)	componentDidMount / componentDidUpdate, etc.	Lets you recover with fallback UI
Errors in constructors (class components)	During component creation	Stops faulty subtree from taking down the app

What Error Boundaries are designed to catch

JSX

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    // log to monitoring (Sentry, etc.)
    console.error(error, info);
  }

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

function App() {
  return (
    <ErrorBoundary>
      <BuggyWidget />
    </ErrorBoundary>
  );
}

Key limitation

Error Boundaries only catch errors that happen while React is rendering/committing the UI tree for descendants.

They are not a general-purpose try/catch for everything in your app.

What they do NOT catch	Example	How to handle instead
Event handler errors	onClick / onSubmit throws	Use try/catch in the handler + report/log
Async errors	setTimeout / promise / async/await throws	Catch with .catch / try/catch and set error state
Errors in the Error Boundary itself	Fallback UI throws	Wrap higher or fix boundary; keep fallback simple
Errors outside React tree	Global scripts, non-React code	window.onerror / monitoring integration
SSR rendering errors (server-side)	Server render throws before client loads	Handle on server/framework level + return error page

What Error Boundaries don’t catch

JSX

function Button() {
  const onClick = () => {
    // ❌ Error Boundaries do NOT catch this
    throw new Error('Boom in event handler');
  };

  return <button onClick={onClick}>Click me</button>;
}

function SaferButton() {
  const onClick = () => {
    try {
      throw new Error('Boom');
    } catch (e) {
      // ✅ handle + report
      console.error(e);
    }
  };

  return <button onClick={onClick}>Click me</button>;
}

Where to place Error Boundaries (practical)

Don’t wrap the entire app with one giant boundary only. Use a few strategically placed boundaries so failure is isolated:

• Page-level boundary (keeps navbar/layout alive)
• Widget/card boundary (dashboard tiles don’t nuke the whole page)
• Route boundary (one route fails, rest of app still usable)

Rule of thumb

Use Error Boundaries to protect the UI tree from render-time crashes. Use normal error handling for user interactions and async work.

Interview framing

Say it like this:
"Error Boundaries catch errors during rendering and lifecycle/constructor of descendants, letting React show a fallback UI instead of crashing the whole tree. They do not catch errors in event handlers, async callbacks, SSR, or errors inside the boundary itself — those need explicit try/catch or promise handling."

Summary

Error Boundaries prevent render-time exceptions in a subtree from crashing the entire UI by rendering a fallback and optionally reporting the error. They catch render/commit-time errors in descendants but not event handler errors, async errors, SSR errors, or errors in the boundary itself.