Which failures does a render-time error boundary not catch, and what catches those instead?

## The rule behind the list A boundary is not a general exception hook; it is a feature of the runtime's **work loop**. When the runtime renders or commits, it is the caller of your code, so it can wrap that call and unwind to an ancestor handler if it throws. The single question that decides whether a boundary sees a throw is therefore: *was the runtime on the stack, producing or applying output, when the throw happened?* If you scheduled the code and the host called it back later, the runtime is not on the stack. It has no work in progress to abandon, no subtree to replace, and no reason to look for an ancestor handler. ## What escapes, and what catches it | Where the throw happens | Does a render boundary see it? | What can catch or observe it | |---|---|---| | A render function, template expression or computed value | yes | the nearest ancestor handler | | Applying changes to the host (the commit) | usually yes | the nearest ancestor handler | | An event handler invoked by host event dispatch | no | your own `try`/`catch`; the page's global error event | | A timer or frame callback | no | a `try`/`catch` in the callback; the global error event | | A rejected promise nobody observed | no | a rejection handler on the chain; the global unhandled-rejection event | | Code inside the boundary's own fallback | no — it is the boundary's output | the next handler above it | | A throw while a subtree is being torn down | often not recoverable | runtimes vary; treat it as report-only | | A throw in the server-rendered first pass | no mounted tree to swap | the request must degrade or fail | Two entries deserve unpacking. **Teardown.** When cleanup code throws, the runtime is already dismantling the very tree a boundary would re-render. There is nothing coherent to put a fallback into, and the failed cleanup has probably leaked whatever it was supposed to release — a subscription, a timer, an observer. Runtimes differ in whether such a throw reaches a handler at all, so the safe design is that cleanup never throws: guard it, and swallow-and-report rather than propagate. **Async work that outlives its component.** A request started by a component that has since been torn down can reject long after the subtree is gone. No boundary applies, because the component it belonged to no longer exists. This is why in-flight work wants cancellation on teardown rather than error handling after it. ## Why the global nets are not a substitute A global error listener and a global unhandled-rejection listener sit **outside** the component tree. They receive an error object and, at best, a stack; they have no idea which subtree was involved and no ability to render anything in its place. Their honest jobs are: - **report** the failure to monitoring, with the current view and build identity attached; - **notify** the user out-of-band — a toast, a banner in the shell; - **decide about the process** — offer a reload when the application's own state is likely corrupt; - **stop the default noise**, so the host does not just print to the console. What they cannot do is contain. That asymmetry is why "we have a global handler, we do not need boundaries" is wrong, and equally why "we have boundaries everywhere, we do not need global handlers" is wrong: the two cover disjoint failure sources. ## Designing for the gap 1. **Wrap intent, not everything.** In an event handler, wrap the risky call and turn the failure into state the component can render — an inline message, a disabled control, a retry affordance. That keeps the failure in the component's own vocabulary instead of relying on any global net. 2. **Never leave a rejection unobserved.** Attach handling where the work is started, so failure becomes data. An unhandled rejection is a bug report with no address on it. 3. **Cancel on teardown.** Tie in-flight work to the lifetime of the thing that started it, so results and rejections cannot arrive for a subtree that is gone. 4. **Make cleanup unthrowable.** Cleanup runs during a teardown that may itself be a recovery step; a throw there can turn one contained failure into an uncontained one. 5. **Keep a global net anyway.** It is the only thing that sees the classes above, and the only place a completely unexpected failure becomes visible at all. A last note on development builds: many runtimes deliberately surface caught errors loudly in development — rethrowing to the host, or showing an overlay — while production shows only your fallback. The same code can therefore look like a crash on a developer's machine and like a quiet fallback in production. Do not read that difference as two different bugs, and never rely on the development behaviour to tell you a failure is happening in production; only reporting does that.