Wie gehst du mit Laufzeitfehlern in einem React-Baum um?

Error Boundaries fangen Fehler, die während des Renderns, in Lifecycle-Methoden und in Konstruktoren unterhalb von ihnen geworfen werden, und rendern dann einen Fallback, statt die ganze App abzuwerfen. Sie sind weiterhin Klassenkomponenten mit getDerivedStateFromError und componentDidCatch, oder eine Wrapper-Library. Fehler in Event-Handlern, async-Callbacks oder in der Boundary selbst fangen sie nicht, dafür brauchst du normales try und catch plus Reporting.

Error Boundaries fangen alles, was beim Rendern des Teilbaums unter ihnen geworfen wird, und tauschen einen Fallback ein, damit ein kaputtes Widget nicht die ganze Seite mitnimmt. Ich nehme meist den Wrapper react-error-boundary, statt die Klasse selbst zu schreiben, weil ich damit einen Reset-Handler geschenkt bekomme. Die Lücken sind der Teil, den Leute vergessen: Nichts, was in einem onClick, einem setTimeout oder einer unbehandelten Promise-Rejection geworfen wird, erreicht eine Boundary, dafür braucht es weiter try und catch mit einem expliziten Fehlerzustand. Zur Platzierung: Eine Boundary an der Wurzel ist im Grunde nur ein hübscherer Absturzbildschirm. Was ich tatsächlich mache, ist jeden unabhängig nützlichen Bereich einzupacken, Sidebar, Hauptpanel und jedes Drittanbieter-Embed bekommen ihre eigene, mit einem Fallback, der sagt, was fehlgeschlagen ist, und einen Retry anbietet, der die Boundary zurücksetzt und neu lädt. Jede Boundary meldet in componentDidCatch an unser Error-Tracking mit Component Stack und User-Kontext, und in React 19 setze ich zusätzlich onUncaughtError an der Wurzel, damit nichts unprotokolliert durchrutscht.