Using error boundaries in React - Deep Dive

Overview - Using error boundaries

What is it?

Using error boundaries in React means creating special components that catch errors in their child components during rendering, lifecycle methods, and constructors. These boundaries prevent the whole app from crashing by showing a fallback UI instead. They help keep the app running smoothly even when parts of it fail. Error boundaries only catch errors in components below them in the tree, not in themselves or event handlers.

Why it matters

Without error boundaries, a single error in any part of a React app can cause the entire UI to break and show a blank screen or crash. This leads to a poor user experience and lost trust. Error boundaries help isolate problems, letting the rest of the app work normally and showing friendly messages instead of crashes. This makes apps more reliable and easier to maintain.

Where it fits

Before learning error boundaries, you should understand React components, props, state, and how rendering works. After mastering error boundaries, you can explore advanced error handling like logging errors to external services, using React Suspense for data fetching, and improving user experience with retry logic.

Mental Model

Core Idea

An error boundary is like a safety net component that catches errors in its children and shows a fallback UI instead of letting the whole app crash.

Think of it like...

Imagine a circus performer walking on a tightrope with a safety net below. If they slip, the net catches them so they don’t fall all the way down. Similarly, error boundaries catch errors so the app doesn’t crash completely.

App Root
  │
  ├─ Error Boundary (Safety Net)
  │     ├─ Child Component A
  │     └─ Child Component B
  └─ Other Components

If Child Component A throws an error:
Error Boundary catches it → shows fallback UI
Other Components remain unaffected

Build-Up - 7 Steps

1

Foundation

What are error boundaries

Concept: Error boundaries are React components that catch JavaScript errors in their child components during rendering and lifecycle methods.

In React, errors thrown inside components usually crash the whole app. Error boundaries are special components that catch these errors and let you show a fallback UI instead of crashing. They are created by defining a class component with specific lifecycle methods.

Result

When an error happens inside a child component, the error boundary catches it and renders a fallback UI instead of the broken component tree.

Understanding that React apps can crash from errors and that error boundaries prevent this is key to building resilient user interfaces.

2

Foundation

Creating a basic error boundary

Concept: You create an error boundary by making a class component with static getDerivedStateFromError and componentDidCatch methods.

A basic error boundary looks like this: class ErrorBoundary extends React.Component { constructor(props) { super(props); this.state = { hasError: false }; } static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { // You can log error info here } render() { if (this.state.hasError) { return

Something went wrong.

; } return this.props.children; } }

Result

This component catches errors in its children and shows a simple message instead of crashing the app.

Knowing the two lifecycle methods that make error boundaries work helps you build your own safety nets in React.

3

Intermediate

Where error boundaries catch errors

🤔Before reading on: Do you think error boundaries catch errors in event handlers or only during rendering? Commit to your answer.

Concept: Error boundaries catch errors during rendering, lifecycle methods, and constructors of child components, but not in event handlers or asynchronous code.

Error boundaries catch errors that happen while React is rendering components or running lifecycle methods like componentDidMount. However, errors inside event handlers (like onClick) are not caught by error boundaries because React treats them differently. You need to handle those errors with try/catch inside the event handler.

Result

You learn that error boundaries protect the UI rendering process but you still need to handle other errors separately.

Understanding the limits of error boundaries prevents confusion and helps you write better error handling code in React.

4

Intermediate

Using error boundaries with fallback UI

🤔Before reading on: Should the fallback UI be static text only, or can it be a full React component? Commit to your answer.

Concept: The fallback UI shown by error boundaries can be any React element, including complex components with buttons or retry logic.

Instead of just showing a simple message, you can render a full React component as fallback. For example, a component with a button to reload the page or reset the error state: render() { if (this.state.hasError) { return this.setState({ hasError: false })} />; } return this.props.children; }

Result

Users see a friendly UI that can help recover from errors instead of a plain message.

Knowing you can customize fallback UI improves user experience and makes your app feel polished.

5

Intermediate

Handling multiple error boundaries

🤔Before reading on: If you nest error boundaries, which one catches an error in a deeply nested component? Commit to your answer.

Concept: You can nest error boundaries to isolate errors in different parts of the app, and the closest boundary to the error catches it.

For example: If ComponentB throws an error, the inner ErrorBoundary catches it. If ComponentA throws an error outside ComponentB, the outer ErrorBoundary catches it.

Result

Errors are caught by the nearest error boundary, allowing fine-grained control over error handling.

Understanding error boundary nesting helps you design robust apps that isolate failures without affecting unrelated parts.

6

Advanced

Logging errors with componentDidCatch

🤔Before reading on: Do you think componentDidCatch can modify state or only log errors? Commit to your answer.

Concept: componentDidCatch lets you log error details to external services but should not be used to update state; state updates belong in getDerivedStateFromError.

Inside componentDidCatch(error, info), you can send error info to logging services like Sentry or your own backend: componentDidCatch(error, info) { logErrorToService(error, info.componentStack); } State updates to show fallback UI happen in getDerivedStateFromError.

Result

You can track errors in production and fix bugs faster without affecting UI rendering.

Separating error logging from UI state updates clarifies responsibilities and prevents bugs in error boundaries.

7

Expert

Limitations and pitfalls of error boundaries

🤔Before reading on: Can error boundaries catch errors in asynchronous code like promises? Commit to your answer.

Concept: Error boundaries do not catch errors in asynchronous code, server-side rendering, or errors thrown in the error boundary itself.

If an error happens inside a promise or async function, error boundaries won't catch it. You must handle those errors with try/catch or .catch. Also, errors in the error boundary component itself will crash the app. React 18 introduced new ways to handle errors with Suspense and server components, but error boundaries remain client-side UI safety nets.

Result

You understand the limits of error boundaries and know when to use other error handling techniques.

Knowing these limits prevents over-reliance on error boundaries and encourages comprehensive error handling strategies.

Under the Hood

Error boundaries work by implementing two special lifecycle methods in class components: getDerivedStateFromError and componentDidCatch. When a child component throws an error during rendering or lifecycle, React walks up the component tree to find the nearest error boundary. React then calls getDerivedStateFromError to update the error boundary's state, triggering a re-render with fallback UI. componentDidCatch is called afterward to log error details. This mechanism isolates errors and prevents React's reconciliation process from crashing the entire app.

Why designed this way?

React was designed to be declarative and resilient. Before error boundaries, any error in rendering crashed the whole app, which was unacceptable for large apps. The design of error boundaries as class components with specific lifecycle methods fits React's component model and lifecycle. Alternatives like try/catch around render would be cumbersome and break React's declarative nature. The separation of state update and logging methods allows clear responsibilities and better error handling.

┌─────────────────────────────┐
│       React App Root        │
└─────────────┬───────────────┘
              │
      ┌───────▼────────┐
      │ Error Boundary  │
      │  (hasError?)    │
      └───────┬────────┬┘
              │        │
   Error thrown in   No error
   child component   in child
        │              │
┌───────▼────────┐     │
│ getDerivedState│     │
│ FromError sets │     │
│ hasError=true  │     │
└───────┬────────┘     │
        │              │
┌───────▼────────┐     │
│ Render fallback│     │
│ UI instead of  │     │
│ children       │     │
└───────┬────────┘     │
        │              │
┌───────▼────────┐     │
│ componentDidCatch│   │
│ logs error info │    │
└─────────────────┘    │
                       │
               Render children normally

Myth Busters - 4 Common Misconceptions

Quick: Do error boundaries catch errors in event handlers? Commit to yes or no.

Common Belief: Error boundaries catch all errors in React components, including event handlers.

Reality: Error boundaries do NOT catch errors inside event handlers; those must be handled with try/catch inside the handler.

Why it matters: Assuming error boundaries catch event handler errors leads to uncaught exceptions and app crashes.

Quick: Can error boundaries catch errors thrown in asynchronous code like promises? Commit to yes or no.

Common Belief: Error boundaries catch errors thrown anywhere in the component, including async code.

Reality: Error boundaries only catch errors during rendering and lifecycle methods, not in asynchronous code like promises or setTimeout.

Why it matters: Believing otherwise causes missed errors and unexpected crashes in async operations.

Quick: If an error boundary itself throws an error, will React catch it with another boundary? Commit to yes or no.

Common Belief: Error boundaries protect themselves and other boundaries from errors inside their own code.

Reality: If an error boundary throws an error, React cannot catch it with another boundary, and the app crashes.

Why it matters: This misconception can lead to fragile error boundaries that cause app crashes instead of preventing them.

Quick: Does nesting error boundaries mean all errors are caught by the outermost one? Commit to yes or no.

Common Belief: All errors bubble up to the outermost error boundary regardless of nesting.

Reality: Errors are caught by the nearest error boundary in the component tree, not always the outermost one.

Why it matters: Misunderstanding this leads to poor error boundary placement and less effective error isolation.

Expert Zone

1

Error boundaries only work with class components because they rely on lifecycle methods; functional components cannot be error boundaries directly, but hooks like useErrorHandler can help simulate similar behavior.

2

When multiple error boundaries catch the same error, only the nearest one handles it; others do not get notified, so logging and recovery must be planned carefully.

3

React 18's concurrent rendering can cause error boundaries to behave differently under Suspense and transitions, requiring careful testing to avoid unexpected fallback UI flashes.

When NOT to use

Do not use error boundaries to catch errors in event handlers, asynchronous code, or server-side rendering. Instead, use try/catch blocks inside event handlers, promise catch handlers, or error handling middleware on the server. Also, avoid using error boundaries to hide bugs during development; they are meant for production resilience.

Production Patterns

In production, error boundaries are often placed around major UI sections like page layouts or feature modules to isolate failures. They are combined with error logging services to track issues. Some apps implement retry buttons or reset logic in fallback UI to improve user experience. Advanced patterns include wrapping third-party components with error boundaries to prevent external bugs from crashing the app.

Connections

Try/Catch in JavaScript

Error boundaries are React’s version of try/catch but work at the component tree level during rendering.

Understanding try/catch helps grasp why error boundaries can’t catch asynchronous errors and why they must be class components with lifecycle methods.

Circuit Breaker Pattern in Software Design

Error boundaries act like circuit breakers that isolate failing parts to prevent cascading failures.

Knowing circuit breakers in distributed systems helps appreciate how error boundaries improve app stability by isolating errors.

Fault Tolerance in Engineering

Error boundaries implement fault tolerance by catching errors and providing fallback behavior to keep the system running.

Recognizing error boundaries as fault tolerance mechanisms connects software design to broader engineering principles of reliability.

Common Pitfalls

#1 Placing error boundaries too low in the component tree causing many small fallback UIs.

Wrong approach:

Correct approach:

Root cause:

Misunderstanding error boundary scope leads to fragmented error handling and poor user experience.

#2 Trying to use error boundaries as functional components.

Wrong approach:

function ErrorBoundary({ children }) {
try {
return children;
} catch (e) {
return ;
}
}

Correct approach:

class ErrorBoundary extends React.Component {
// implement getDerivedStateFromError and componentDidCatch
}

Root cause:

Not knowing error boundaries require lifecycle methods only available in class components.

#3 Not resetting error state after showing fallback UI, causing permanent fallback display.

Wrong approach:

class ErrorBoundary extends React.Component {
state = { hasError: false };
static getDerivedStateFromError() { return { hasError: true }; }
render() {
if (this.state.hasError) return ;
return this.props.children;
}
}

Correct approach:

Add a method to reset state, e.g., on retry button:
this.setState({ hasError: false });

Root cause:

Forgetting to provide a way to recover from errors traps users in fallback UI.

Key Takeaways

Error boundaries are special React class components that catch errors in their child components during rendering and lifecycle methods to prevent the whole app from crashing.

They do not catch errors in event handlers, asynchronous code, or server-side rendering, so other error handling methods are needed for those cases.

You can nest error boundaries to isolate errors in different parts of your app, and the nearest boundary to the error handles it.

Error boundaries separate UI fallback rendering from error logging, allowing you to show friendly messages while tracking issues behind the scenes.

Understanding the limits and proper placement of error boundaries is essential for building resilient and user-friendly React applications.