Ein UNBEHANDELTER JavaScript-Fehler beim Rendern einer Komponente (z. B. undefined.someProperty) lässt standardmäßig die GESAMTE React-App abstürzen – ein weißer Bildschirm statt einer funktionierenden Anwendung. Error Boundaries verhindern das, indem sie Fehler auf einen bestimmten Teilbaum begrenzen.

Warum normales try/catch nicht funktioniert

try/catch fängt Fehler in IMPERATIVEM Code (Funktionsaufrufe, Schleifen) – aber Reacts Rendering-Prozess läuft nicht innerhalb Ihres eigenen try-Blocks, sondern TIEF innerhalb Reacts eigener interner Aufrufkette. Ein try/catch UM <ProductCard /> in Ihrem eigenen Code fängt einen Fehler, der WÄHREND des Renderns von ProductCard auftritt, schlicht NICHT ab.

Die einzige verbliebene Pflicht-Anwendung von Klassenkomponenten

Bemerkenswerte Ausnahme im sonst hooks-basierten modernen React: Error Boundaries MÜSSEN (Stand heute, React 18/19) als Klassenkomponente geschrieben werden – es gibt keinen Hook-Ersatz für static getDerivedStateFromError und componentDidCatch. Das ist einer der wenigen Orte, an dem Sie in modernem React noch echten Klassen-Syntax sehen werden.

import { Component } from 'react';

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

  // Wird während der Render-Phase aufgerufen, direkt NACHDEM ein Fehler geworfen wurde -
  // muss den neuen State zurückgeben, DARF keine Seiteneffekte auslösen (siehe Kapitel 35
  // zur Render-Phase: sie muss "rein" bleiben, auch im Fehlerfall).
  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  // Wird NACH dem Commit aufgerufen - HIER dürfen Seiteneffekte passieren,
  // z. B. den Fehler an einen Error-Tracking-Dienst senden.
  componentDidCatch(error, errorInfo) {
    console.error('ErrorBoundary hat einen Fehler abgefangen:', error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      return (
        <div className="error-boundary-fallback">
          <h2>Etwas ist schiefgelaufen.</h2>
          <p>Dieser Bereich der Seite konnte nicht geladen werden.</p>
          <button onClick={() => this.setState({ hasError: false })}>
            Erneut versuchen
          </button>
        </div>
      );
    }

    return this.props.children;
  }
}

export default ErrorBoundary;

Die zwei Methoden im Detail

• getDerivedStateFromError ist STATISCH (kein Zugriff auf this) und läuft VOR dem nächsten Render – ihr einziger Zweck ist, den State so zu setzen, dass die Fallback-UI beim nächsten Render angezeigt wird.
• componentDidCatch läuft NACH dem Commit und bekommt zusätzlich errorInfo (u. a. den Component-Stack) – hier gehört das eigentliche Logging/Reporting hin, niemals in getDerivedStateFromError.

Praxis: ProductListPage gegen fehlerhafte API-Antworten absichern

Wir setzen die ErrorBoundary um die Produktliste in App.jsx – sollte ProductListPage (oder eine ihrer Kindkomponenten) unerwartet abstürzen, bleibt der Rest der App (Header, Navigation) funktionsfähig:

// In App.jsx, ProductListPage einpacken:
import ErrorBoundary from './components/ErrorBoundary';

// ... in den Routes:
<Route
  path="/"
  element={
    <ErrorBoundary>
      <ProductListPage />
    </ErrorBoundary>
  }
/>

Strategische Platzierung: nicht nur EINE globale Boundary

Eine einzelne ErrorBoundary ganz oben um die GESAMTE App würde bei JEDEM Fehler die komplette Anwendung durch die Fallback-UI ersetzen – oft übertrieben. Besser: mehrere, GEZIELT platzierte Boundaries um unabhängige Seitenbereiche (wie hier um ProductListPage, könnte man ebenso separat um CartWidget im Header legen) – ein Fehler in einem Bereich reißt dann nicht die gesamte restliche Seite mit.