React error boundary wraps main application
Why it matters
Without a root-level error boundary, a single thrown exception in any React component silently blanks the entire application — users see a white screen with no explanation and no recovery path. CWE-755 (Improper Handling of Exceptional Conditions) names this directly: the absence of fault tolerance at the application boundary turns transient bugs into total outages. For Next.js App Router projects, a route-level error.tsx alone is insufficient — errors in the root layout bypass it entirely, requiring global-error.tsx as a separate boundary. ISO 25010 reliability.fault-tolerance classifies the absence of this pattern as a direct reliability failure.
Severity rationale
Critical because a missing root boundary converts any unhandled render exception into a full application crash with no user-visible recovery path.
Remediation
Add both app/global-error.tsx and app/error.tsx for Next.js App Router — the global file is mandatory because route-level boundaries don't cover root layout errors.
// app/global-error.tsx
'use client'
export default function GlobalError({ error, reset }: { error: Error; reset: () => void }) {
return (
<html>
<body>
<h2>Something went wrong</h2>
<button onClick={() => reset()}>Try again</button>
</body>
</html>
)
}
For non-Next.js React apps, wrap the root render point with react-error-boundary. Verify by intentionally throwing in a component during development and confirming the fallback UI appears instead of a blank page.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Error Handling Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-755 — Improper Handling of Exceptional Conditions
- iso-25010:2011 · reliability.fault-tolerance
Taxons
History
- 2026-04-18·v1.0.0·Initial import from saas-error-handling·automated