What an ErrorBoundary catches
What an ErrorBoundary catches in the Error handling guide.
| Where the error is thrown | Caught by the boundary |
|---|---|
| A component body or JSX expression while the children are created | Yes |
An effect (useEffect, useRenderEffect, a compiler binding), later |
Yes: the whole boundary content is replaced |
| A memo, when an effect or binding reads it | Yes: memos store the error and rethrow it to every reader |
A cleanup (onCleanup, a returned cleanup) |
Yes |
A resource that rejected, when it is read (data()) |
Yes |
| The fallback itself | No: it goes to the enclosing boundary |
| An event handler | No: handlers run outside the owner tree; the error reaches the browser (window error event) |
A promise rejection or an async function |
No: route it with handleError (below) |
| After the boundary was disposed | Dropped without effect |
Design notes for the table above:
- A boundary replaces all of its content. An error in one row of a list inside a boundary replaces the whole boundary, so wrap risky parts in their own boundaries.
- Errors raised while the boundary is building or tearing down its children are captured without writing signals, because writing signals inside a memo is an error. Late errors re-run the boundary.
resetis idempotent. Calling it twice builds the children once. After the boundary is disposed it does nothing. If the children still throw, the fallback is shown again.- A fallback that is not a function is shown as is. A function fallback is called once per error, untracked.