The Complete Guide to React Error Handling in 2026

It happens to the best of us. A null value slips through, a network request fails, or a third-party library explodes. Suddenly, your beautiful React app is a blank white screen. Only the console knows the truth: Uncaught TypeError: Cannot read properties of undefined.

In 2026, React gives us powerful tools to catch these errors and fail gracefully. This guide covers everything from Error Boundaries to async handling and logging.

Why "White Screens" Happen

By default, if a JavaScript error occurs inside a React component's rendering logic, React unmounts the entire component tree.

"A JavaScript error in a part of the UI should not break the whole app. To solve this problem for React users, React 16 introduces a new concept of an 'error boundary'." — React Docs

If you don't handle errors, your user sees nothing. No header, no footer, no "Oops" message. Just a blank tab. That is the worst possible user experience.

Figure 1: A broken app vs. a graceful recovery using Error Boundaries.

Strategy 1: Error Boundaries (The UI Safety Net)

Error Boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed.

Class-Based (Classic)

Even in 2026, Error Boundaries technically still require a class component to use componentDidCatch or getDerivedStateFromError.

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

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

  componentDidCatch(error, errorInfo) {
    logErrorToService(error, errorInfo);
  }

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

Functional Usage (react-error-boundary)

Most developers today use the react-error-boundary library to avoid writing classes.

import { ErrorBoundary } from "react-error-boundary";

function Fallback({ error, resetErrorBoundary }) {
  return (
    <div role="alert">
      <p>Something went wrong:</p>
      <pre>{error.message}</pre>
      <button onClick={resetErrorBoundary}>Try again</button>
    </div>
  );
}

<ErrorBoundary FallbackComponent={Fallback}>
  <MyWidget />
</ErrorBoundary>

Where to place them?

1. Top Level: Wrap your whole app to prevent white screens.
2. Feature Level: Wrap complex widgets (e.g., a Sidebar or Dashboard Chart). If the chart crashes, the sidebar should still work.

Strategy 2: Async Error Handling

Error Boundaries generally do not catch errors inside:

• Event handlers (onClick)
• Asynchronous code (setTimeout, fetch)
• Server-side rendering (SSR)

For these, you need traditional try/catch.

Try/Catch in Effects

useEffect(() => {
  async function loadData() {
    try {
      const data = await fetchAPI();
      setData(data);
    } catch (error) {
      setError(error); // Manage error state manually
      console.error("API Failed", error);
    }
  }
  loadData();
}, []);

The useErrorBoundary Hook

If you want to trigger your Error Boundary from an async function (so the UI is replaced with the fallback), you can "throw" the error into React's state using react-error-boundary.

import { useErrorBoundary } from "react-error-boundary";

function MyComponent() {
  const { showBoundary } = useErrorBoundary();

  async function handleSubmit() {
    try {
      await submitForm();
    } catch (error) {
      showBoundary(error); // This triggers the parent Error Boundary!
    }
  }
}

Strategy 3: React 19 & Next.js Error handling

Modern frameworks like Next.js integrate error handling into their routing.

file: error.tsx

In Next.js App Router, simply creating an error.tsx file in a route segment automatically wraps that segment in an Error Boundary.

// app/dashboard/error.tsx
'use client' // Error components must be Client Components
 
export default function Error({ error, reset }) {
  return (
    <div>
      <h2>Something went wrong!</h2>
      <button onClick={() => reset()}>Try again</button>
    </div>
  )
}

This is the standard in 2026. It's file-system based and extremely intuitive.

10 Common Mistakes (And How to Fix Them)

1. No Global Boundary

Mistake: No Error Boundary at the root. Fix: Always wrap app or main in a generic generic boundary. Why: Prevent total app death (White Screen of Death).

2. Over-using Boundaries

Mistake: Wrapping every single button in a boundary. Fix: Group related components (e.g., wrap the whole Form, not each Input). Why: Too many boundaries create a disjointed UI when things fail.

3. Ignoring Async Errors

Mistake: Expecting Error Boundaries to catch fetch failures. Fix: Use try/catch or showBoundary(). Why: Boundaries only catch render/lifecycle errors.

4. Poor Fallback UI

Mistake: Showing a scary stack trace to end users. Fix: Show a friendly "Oops" message and a "Reload" button. Why: Detailed errors scare non-technical users.

5. Not Logging

Mistake: Catching the error but swallowing it. Fix: Send errors to Sentry, LogRocket, or your own logging service. Why: If you don't know it's breaking, you can't fix it.

6. Infinite Retry Loops

Mistake: resetErrorBoundary immediately causing the same error again. Fix: Ensure onReset clears the cache or state that caused the error. Why: Infinite loops crash the browser tab.

7. Missing "Key" Reset

Mistake: React not re-mounting the component after error. Fix: React Error Boundary usually handles this, but sometimes you need to change a key prop to force a fresh mount. Why: Stale state usually causes the same crash again.

8. Confusing 404s with Crashes

Mistake: Showing a "Crash" screen for a "Not Found" error. Fix: Handle 404s specifically (e.g. notFound() in Next.js). Why: A missing page is not a code failure; treat it differently.

9. Leaking Sensitive Info

Mistake: Displaying error.message directly in production. Fix: Show generic messages to users; log specifics to developers. Why: Exception messages can reveal path names, IDs, or logic flaws.

10. Breaking Hooks Rules

Mistake: Conditional hooks causing weird errors. Fix: Always verify "Rendered more hooks than during the previous render" errors. Why: These are development errors that break boundaries often.

[!NOTE] Looking for more advanced debugging? check out DevTools Limitations in Modern React Debugging to see why console.log isn't enough anymore.

Debugging Errors with DevConsole

When an error happens in production, you need context. DevConsole helps you simulate and debug:

Replay the State

State management bugs often cause crashes. DevConsole lets you verify the exact Redux/Context state at the moment of failure.

Mock API Failures

Don't wait for your server to go down. Use DevConsole to force 500 errors on your API endpoints and verify your fallbacks appear correctly.

Performance Impact

Did the error handling code slow down the app? Check the render timings in DevConsole.

Error Handling Checklist

Before shipping:

• [✓] Root Error Boundary installed

• [✓] Granular boundaries around complex widgets (Maps, Graphs, Editors)

• [✓] error.tsx pages created (for Next.js apps)

• [✓] Async functions wrapped in try/catch

• [✓] logging service configured (Sentry/Datadog)

• [✓] Fallback UIs have "Retry" buttons

• [✓] Verified Fallback UI works on Mobile

• [✓] Checked that reset actually fixes the state

• [✓] Suppressed technical error details in Prod

• [✓] Suppressed technical error details in Prod

Frequently Asked Questions (FAQ)

Q: Do Error Boundaries catch async errors (like fetch failing)?

A: No. Error Boundaries only catch errors during rendering, lifecycle methods, and constructors. For async code, use try/catch or libraries like react-query which have built-in error states.

Q: Can I use Error Boundaries with Functional Components?

A: Yes, but you either need to write one class component yourself or (highly recommended) use the react-error-boundary library which provides a functional wrapper.

Q: specific errors to Sentry vs Console?

A: In development, log everything to Console. In production, log "caught" errors to Sentry but show a generic message to users. Never show stack traces to end-users.

Q: Why does my error boundary show up in development but not production?

A: In Development mode, React purposefully "bubbles" the error to the browser overly to help you debug. The Error Boundary is working, but the browser overlay sits on top of it. Press Esc to see your boundary beneath.

Conclusion

Errors are inevitable. A broken app is not.

The measure of a quality React app isn't that it never crashes—it's that it crashes gracefully. By implementing Error Boundaries and robust async handling, you turn potential churn events into minor inconveniences.

Stop fearing the crash. Manage it.

Have questions? Need help debugging a specific stack trace? Drop a comment below or use DevConsole to deep-dive into your application state.

Want to stress-test your error handling? Try DevConsole to mock failures, intercept requests, and ensure your app is bulletproof.