React Error Boundaries: Why AI-Generated Apps Crash on One Error

What Happens Without an Error Boundary?

Without Error Boundaries, a single uncaught error thrown while rendering any React component will unmount your entire component tree - including your navigation, unrelated sections, and any data the user was entering. The user sees a blank white screen with no explanation. No error message, no "try again" button, nothing.

In a production React app, one uncaught rendering error with no error boundary takes down the whole page. Apps built with Bolt, Lovable, Cursor or v0 are especially exposed, because AI tools prioritize functionality over resilience patterns.

Error Boundaries were introduced in React 16 in 2017. Nine years later, they remain one of the most underused features in the entire React ecosystem - and AI code generators have made the problem worse.

How AI-Generated React Code Fails

Here's a realistic scenario. An AI tool builds a dashboard with a user profile card. The component tries to access user.preferences.theme but the server returns null for preferences. Without an Error Boundary:

// ❌ BAD - No Error Boundary
// If this component throws, the ENTIRE app blanks out

function UserCard({ user }) {
  // If user.preferences is null, this throws a TypeError
  const theme = user.preferences.theme;

  return (
    <div className={`card card-${theme}`}>
      <h2>{user.name}</h2>
    </div>
  );
}

// App.jsx - No protection whatsoever
function App() {
  return (
    <div>
      <Navigation />
      <Dashboard />  {/* If anything inside throws → white screen */}
      <Footer />
    </div>
  );
}

One null-check away from working, but instead: full crash. The navigation disappears. The footer disappears. The user has no way to navigate away except to reload and lose their work.

The Fix: Adding a React Error Boundary

Error Boundaries must be class components (React does not yet support them as hooks), but you write them once and reuse everywhere:

// ✅ GOOD - Reusable Error Boundary component
import { Component } from 'react';

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

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

  componentDidCatch(error, info) {
    // Log to your error tracking service
    console.error('Component error:', error, info.componentStack);
    // e.g. Sentry.captureException(error);
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback || (
        <div className="error-fallback">
          <p>Something went wrong. <button onClick={() => this.setState({ hasError: false })}>Try again</button></p>
        </div>
      );
    }
    return this.props.children;
  }
}

// Wrap individual sections - not just the root
function App() {
  return (
    <div>
      <Navigation /> {/* Nav never crashes */}
      <ErrorBoundary fallback={<p>Dashboard failed to load.</p>}>
        <Dashboard />
      </ErrorBoundary>
      <Footer /> {/* Footer never crashes */}
    </div>
  );
}

Now if Dashboard throws, only that section shows a fallback. Navigation and footer stay intact. The user can still navigate.

Where to Place Error Boundaries

Placement strategy matters. One root-level Error Boundary is better than nothing, but fine-grained boundaries give users a much better experience:

A broken section that leaves the rest of the page working is far easier for users to recover from than a full-page crash. Granular Error Boundaries directly improve recovery rate.

Modern Alternatives: react-error-boundary Library

Writing class components in a hooks-first codebase feels jarring. The react-error-boundary package provides a polished, hook-friendly wrapper:

// ✅ GOOD - Using react-error-boundary package
import { ErrorBoundary } from 'react-error-boundary';

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

function App() {
  return (
    <ErrorBoundary
      FallbackComponent={ErrorFallback}
      onError={(error, info) => logErrorToService(error, info)}
      onReset={() => { /* optional: reset state */ }}
    >
      <Dashboard />
    </ErrorBoundary>
  );
}

This package also provides the useErrorBoundary hook, whose showBoundary function lets you send an error from async code to the nearest boundary - something a plain class boundary does not catch on its own.

What Error Boundaries Do Not Catch

Error Boundaries only catch errors during rendering, in lifecycle methods, and in constructors. They do not catch:

• Errors in event handlers (use try/catch inside the handler)
• Async code like setTimeout or fetch callbacks
• Errors in the Error Boundary component itself
• Server-Side Rendering errors (Next.js has its own error.tsx convention)

For Next.js App Router apps, add an error.tsx file to each route segment: Next.js wraps the segment in a React Error Boundary, so it catches rendering errors from both Server and Client Components in that segment. Add your own boundaries inside a page when one widget failing should not replace the whole segment.

How to Find Missing Error Boundaries in Your App

1. Search your codebase for getDerivedStateFromError or react-error-boundary imports. If neither exists, you have no Error Boundaries.
2. Test by throwing manually: Add throw new Error('test') inside a component and see if the whole app blanks. If it does, you need boundaries.
3. Check your Next.js routes for error.tsx files in each route directory.
4. Automated scanning: Tools like VibeDoctor's Vibe Check automatically flag a React app (FE-010) when they find no error.tsx, no ErrorBoundary file and no error boundary class with componentDidCatch. It is a project-level check, so it tells you the app has no boundary rather than which routes are unprotected. Free to sign up.
5. Add error tracking: Once you have Error Boundaries, connect componentDidCatch to Sentry, Datadog, or LogRocket so you're notified when real users hit errors.

Another React mistake in AI-generated code is an effect with no cleanup. See our guide to memory leaks in useEffect.

FAQ