Why error boundaries matter in NextJS - Visual Breakdown

Concept Flow - Why error boundaries matter

Component Renders

↓

Error Occurs?

No→Normal UI Display

Yes↓

Error Boundary Catches

↓

Show Fallback UI

↓

App Continues Running

This flow shows how error boundaries catch errors during rendering and display fallback UI instead of crashing the whole app.

Execution Sample

NextJS

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

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

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

    return this.props.children;
  }
}

This code shows a simple error boundary that switches to fallback UI when an error is caught.

Execution Table

Step	Action	Error Occurs?	State hasError	UI Rendered
1	Render child component	No	false	Child component UI
2	Child component throws error	Yes	false	Child component UI
3	Set hasError to true	N/A	true	Fallback UI shown
4	User sees fallback UI	N/A	true	Fallback UI shown
5	App continues running	N/A	true	Fallback UI shown

💡 Error boundary caught error and switched UI to fallback, preventing app crash

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
hasError	false	false	true	true

Key Moments - 2 Insights

Why doesn't the app crash when an error happens inside a child component?

Because the error boundary catches the error (see execution_table step 2) and sets hasError to true, switching to fallback UI instead of crashing.

What does the fallback UI do?

It shows a simple message like 'Something went wrong' so users know there was a problem but the app is still running (see execution_table steps 3 and 4).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of hasError right after the error occurs?

A true

B undefined

C false

D null

💡 Hint

Check the 'State hasError' column at step 2 in the execution_table.

At which step does the UI switch to the fallback message?

A Step 2

B Step 3

C Step 1

D Step 5

💡 Hint

Look at the 'UI Rendered' column in the execution_table to see when fallback UI appears.

If the error boundary did not catch errors, what would happen?

A The app would crash and stop running

B The app would show fallback UI anyway

C The error would be ignored silently

D The error would fix itself automatically

💡 Hint

Think about why error boundaries exist, as shown in the concept_flow diagram.

Concept Snapshot

Error boundaries catch errors in child components during rendering.
They prevent the whole app from crashing.
When an error occurs, they show fallback UI.
This keeps the app running smoothly.
Use error boundaries to improve user experience.

Full Transcript

Error boundaries are special components in Next.js that catch errors happening inside their child components during rendering. When an error occurs, instead of the whole app crashing, the error boundary catches it and switches to a fallback UI, like a simple error message. This way, users see a friendly message and the rest of the app keeps working. The execution flow starts with rendering child components. If no error happens, normal UI shows. If an error happens, the error boundary catches it, sets a state variable to show fallback UI, and the app continues running without crashing. This is important to keep apps stable and user-friendly.

Practice

1. What is the main purpose of error boundaries in a Next.js application?

easy

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

B. To improve SEO by optimizing page metadata

C. To handle server-side rendering errors automatically

D. To manage user authentication and sessions

Solution

1. Step 1: Understand error boundaries role

   Error boundaries catch errors in React components during rendering, lifecycle methods, and constructors.

2. Step 2: Identify their main benefit

   They prevent the whole app from crashing by showing a fallback UI instead of a broken screen.

3. Final Answer:

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

4. Quick Check:

   Error boundaries catch errors = B [OK]

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

Common Mistakes:

• Confusing error boundaries with authentication
• Thinking error boundaries improve SEO
• Assuming error boundaries handle server errors automatically

2. Which of the following is the correct way to define an error boundary component in Next.js using React functional components?

easy

A. class ErrorBoundary extends React.Component { constructor() { super(); this.state = { hasError: false }; } componentDidCatch() { this.setState({ hasError: true }); } render() { if (this.state.hasError) return Error occurred; return this.props.children; } }

B. function ErrorBoundary({ children }) { const [hasError, setHasError] = React.useState(false); if (hasError) return Error; return children; }

C. function ErrorBoundary({ children }) { try { return children; } catch { return Error; } }

D. class ErrorBoundary extends React.Component { state = { error: null }; render() { if (this.state.error) return Error; return this.props.children; } }

Solution

1. Step 1: Recall error boundary implementation

   Error boundaries must be class components with lifecycle methods like componentDidCatch to catch errors.

2. Step 2: Check options for correct syntax

   class ErrorBoundary extends React.Component { constructor() { super(); this.state = { hasError: false }; } componentDidCatch() { this.setState({ hasError: true }); } render() { if (this.state.hasError) return <div>Error occurred</div>; return this.props.children; } } correctly defines a class component with constructor, state, componentDidCatch, and render method.

3. Final Answer:

   class ErrorBoundary extends React.Component { constructor() { super(); this.state = { hasError: false }; } componentDidCatch() { this.setState({ hasError: true }); } render() { if (this.state.hasError) return <div>Error occurred</div>; return this.props.children; } } -> Option A

4. Quick Check:

   Error boundaries require class + componentDidCatch = C [OK]

Hint: Error boundaries must be class components with componentDidCatch [OK]

Common Mistakes:

• Trying to create error boundaries as functional components
• Missing componentDidCatch lifecycle method
• Not initializing state to track errors

3. Given the following error boundary component and a child component that throws an error, what will be rendered?

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

function BuggyComponent() {
  throw new Error('Bug!');
  return <div>No bugs</div>;
}

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

medium

A. Uncaught Error: Bug!

B. No bugs

C. Something went wrong.

D. Blank screen

Solution

1. Step 1: Understand error throwing in child

   BuggyComponent throws an error immediately when rendered.

2. Step 2: Check error boundary response

   ErrorBoundary catches the error in componentDidCatch and sets hasError to true, rendering fallback UI.

3. Final Answer:

   <h1>Something went wrong.</h1> -> Option C

4. Quick Check:

   Error caught, fallback UI shown = A [OK]

Hint: ErrorBoundary shows fallback UI when child throws error [OK]

Common Mistakes:

• Expecting child component output despite error
• Thinking error is uncaught and crashes app
• Assuming blank screen instead of fallback UI

4. You have this error boundary component but it does not catch errors as expected. What is the likely problem?

function ErrorBoundary({ children }) {
  try {
    return children;
  } catch (error) {
    return <div>Error occurred</div>;
  }
}

medium

A. Try-catch works fine for error boundaries in functional components

B. Error boundaries must be class components with componentDidCatch method

C. You forgot to wrap children in a React.Fragment

D. You need to use useErrorBoundary hook instead

Solution

1. Step 1: Analyze error boundary implementation

   Try-catch inside a functional component does not catch errors during rendering lifecycle in React.

2. Step 2: Recall React error boundary requirements

   Error boundaries must be class components implementing componentDidCatch lifecycle method to catch errors properly.

3. Final Answer:

   Error boundaries must be class components with componentDidCatch method -> Option B

4. Quick Check:

   Functional try-catch won't catch render errors = A [OK]

Hint: Error boundaries require class + componentDidCatch, not try-catch [OK]

Common Mistakes:

• Using try-catch in functional components expecting error boundary behavior
• Assuming React has a useErrorBoundary hook
• Thinking wrapping children in fragments fixes error catching

5. You want to add a reset button in your error boundary to let users try again after an error. Which approach correctly implements this behavior?

hard

A. Use a useEffect hook to reset error state automatically after 5 seconds

B. Reload the entire page using window.location.reload() when the button is clicked

C. Wrap the reset button in a try-catch block to prevent errors

D. Add a button that calls this.setState({ hasError: false }) inside the error boundary's fallback UI

Solution

1. Step 1: Understand reset behavior in error boundaries

   Resetting error state allows the component tree to re-render normally after an error.

2. Step 2: Identify correct reset method

   Calling this.setState({ hasError: false }) inside the error boundary resets the error state and shows children again.

3. Final Answer:

   Add a button that calls this.setState({ hasError: false }) inside the error boundary's fallback UI -> Option D

4. Quick Check:

   Reset error state with setState = D [OK]

Hint: Reset error by setting hasError false in state [OK]

Common Mistakes:

• Reloading page instead of resetting state
• Using try-catch around reset button unnecessarily
• Relying on automatic reset with useEffect without user action