Why Using error boundaries in React? - Purpose & Use Cases

The Big Idea

What if one tiny bug could crash your whole app--how do you stop that from happening?

The Scenario

Imagine your React app crashes completely because one small component has a bug. The whole page goes blank or shows a confusing error.

The Problem

Without error boundaries, a single error breaks the entire React component tree below it. This means users see a broken app and developers struggle to isolate the problem.

The Solution

Error boundaries catch errors in components below them and show a fallback UI instead of crashing the whole app. This keeps the app running smoothly and helps find bugs faster.

Before vs After

✗ Before

function App() {
  return <BuggyComponent />;
}

✓ After

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

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

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

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

What It Enables

You can build resilient React apps that stay alive and user-friendly even when parts fail unexpectedly.

Real Life Example

On a shopping site, if the product review section crashes, error boundaries let the rest of the page load so customers can still buy items.

Key Takeaways

Errors in React can break the whole UI without protection.

Error boundaries catch these errors and show fallback content.

This improves user experience and helps debugging.

Practice

1. What is the main purpose of an error boundary in React?

easy

A. To handle user input validation in forms

B. To manage state updates in functional components

C. To catch JavaScript errors in child components and display a fallback UI

D. To optimize rendering performance by memoizing components

Solution

1. Step 1: Understand error boundaries role

   Error boundaries catch errors in the rendering phase of child components to prevent the whole app from crashing.

2. Step 2: Identify the correct purpose

   They show a fallback UI instead of letting the error crash the app, improving user experience.

3. Final Answer:

   To catch JavaScript errors in child components and display a fallback UI -> Option C

4. Quick Check:

   Error boundaries catch errors = D [OK]

Hint: Error boundaries catch errors and show fallback UI [OK]

Common Mistakes:

• Thinking error boundaries manage state
• Confusing error boundaries with performance tools
• Assuming error boundaries handle form validation

2. Which of the following is the correct way to define an error boundary component in React?

easy

A. A class component implementing static getDerivedStateFromError and componentDidCatch methods

B. A functional component using useErrorBoundary hook

C. A class component with only render method

D. A functional component with useEffect to catch errors

Solution

1. Step 1: Recall error boundary requirements

   Error boundaries must be class components that implement static getDerivedStateFromError and componentDidCatch lifecycle methods.

2. Step 2: Match the correct syntax

   Only a class component implementing static getDerivedStateFromError and componentDidCatch methods correctly describes this pattern; hooks or functional components cannot be error boundaries.

3. Final Answer:

   A class component implementing static getDerivedStateFromError and componentDidCatch methods -> Option A

4. Quick Check:

   Error boundaries require class + lifecycle methods = B [OK]

Hint: Error boundaries must be class components with special lifecycle methods [OK]

Common Mistakes:

• Trying to use hooks for error boundaries
• Omitting getDerivedStateFromError method
• Using only render method without error handling

3. Given this error boundary component, what will be rendered if BuggyComponent throws an error?

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }
  static getDerivedStateFromError(error) {
    return { hasError: true };
  }
  componentDidCatch(error, info) {
    console.log('Error caught:', error);
  }
  render() {
    if (this.state.hasError) {
      return <h1>Something went wrong.</h1>;
    }
    return this.props.children;
  }
}

// Usage
<ErrorBoundary>
  <BuggyComponent />
</ErrorBoundary>

medium

A. Nothing will render because of a syntax error

B. The original BuggyComponent UI will render normally

C. The app will crash with an uncaught error

D. An error message Something went wrong. will display

Solution

1. Step 1: Understand error boundary behavior on error

   When BuggyComponent throws an error, getDerivedStateFromError sets hasError to true.

2. Step 2: Check render output when error state is true

   The render method returns <h1>Something went wrong.</h1> instead of the child component UI.

3. Final Answer:

   An error message Something went wrong. will display -> Option D

4. Quick Check:

   Error caught shows fallback UI = A [OK]

Hint: Error sets state, triggers fallback UI render [OK]

Common Mistakes:

• Expecting child UI to render despite error
• Thinking app crashes without error boundary
• Confusing syntax error with runtime error

4. Identify the error in this error boundary implementation:

class MyErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { error: null };
  }
  componentDidCatch(error, info) {
    this.setState({ error });
  }
  render() {
    if (this.state.error) {
      return <h2>Error occurred</h2>;
    }
    return this.props.children;
  }
}

medium

A. Missing static getDerivedStateFromError method to update state on error

B. Using setState inside componentDidCatch is not allowed

C. The constructor should not initialize state

D. render method must not return JSX

Solution

1. Step 1: Check error boundary lifecycle requirements

   Error boundaries must implement static getDerivedStateFromError to update state when an error happens.

2. Step 2: Analyze current code

   This code updates state inside componentDidCatch, which is not recommended for triggering fallback UI.

3. Final Answer:

   Missing static getDerivedStateFromError method to update state on error -> Option A

4. Quick Check:

   getDerivedStateFromError required for state update = A [OK]

Hint: Use getDerivedStateFromError to update state on error [OK]

Common Mistakes:

• Updating state only in componentDidCatch
• Ignoring getDerivedStateFromError method
• Thinking setState is forbidden in componentDidCatch

5. You want to use an error boundary to catch errors in multiple components but show different fallback UIs for each. How should you implement this?

hard

A. Use functional components with hooks to catch errors and render fallback UI

B. Create separate error boundary components each with its own fallback UI and wrap each target component accordingly

C. Use one error boundary with a single fallback UI and pass props to customize it dynamically

D. Wrap all components in one error boundary and conditionally render fallback UI inside children

Solution

1. Step 1: Understand error boundary scope

   Error boundaries catch errors in their child component tree and show fallback UI defined inside them.

2. Step 2: Different fallback UIs require separate boundaries

   To show different fallback UIs, create multiple error boundary components each wrapping the target component.

3. Step 3: Evaluate other options

   Using one boundary with dynamic props or hooks is not supported; functional components cannot be error boundaries.

4. Final Answer:

   Create separate error boundary components each with its own fallback UI and wrap each target component accordingly -> Option B

5. Quick Check:

   Different fallback UIs need separate boundaries = C [OK]

Hint: Use multiple error boundaries for different fallback UIs [OK]

Common Mistakes:

• Trying to use one boundary for all with dynamic UI
• Using hooks or functional components as error boundaries
• Wrapping all components in one boundary expecting different UI