error-boundarieslisted

# Error boundaries and failure containment ## The default is a white screen An unhandled render error unmounts the **entire React tree**. Not the broken component — everything. That is deliberate: React would rather show nothing than a corrupted UI. It also means a single unguarded component takes down the whole app. Boundary placement is therefore a design decision about **how much of the UI a failure is allowed to take with it**. ## What a boundary catches, and what it does not **Catches:** errors thrown during render, in lifecycle methods, and in constructors of the tree below it. **Does not catch — and this surprises people:** - errors inside **event handlers** (use try/catch there; the app is not in an inconsistent state, so React does not unmount); - **async errors** — a rejected promise, a `setTimeout` callback, a fetch `.catch` you did not write; - errors in the boundary's **own** render; - **server-side rendering** errors (the framework handles those separately). So a boundary does not make an app error-proof. It contains one specific class — the render throw — and the other classes need their own handling. ## Placement: three levels 1. **Root** — the last resort. A full-page error with a reload option and a report. Something must be here, or an unhandled error is a blank tab. 2. **Route/segment** — the common case. A failure in one route shows an error in the content area while the nav, header and shell survive, so the user can navigate away. In the Next Ap