In React 19, what happens when a promise read with `use()` rejects, and why can't you handle it by wrapping the `use()` call in try/catch?

## The two throws During render, `use(promise)` looks at the promise's status: - **pending** → React needs to stop rendering this component and come back later. Internally it signals that by throwing, which unwinds out of your component function. - **rejected** → the rejection reason is thrown out of the component, exactly like any other error raised during render. - **fulfilled** → the value is returned normally. Both non-happy paths therefore travel by the same mechanism: an exception leaving your function. That single fact explains the whole error story. ## Why try/catch is not supported ```jsx function Profile({ userPromise }) { try { const user = use(userPromise); // React does not support this return <h1>{user.name}</h1>; } catch { return <p>Could not load</p>; } } ``` A `catch` block here catches *whatever* comes out of `use`, and on the very first render that is React's suspension signal, not a failure. Swallowing it means React never learns that the component needs to wait; the component would render its error branch on the first pass and the pending case would silently become the failure case. React documents that `use` cannot be called inside a `try`/`catch` block for this reason. This is not a special quirk of `use`. Render-time errors in React have always been handled by boundaries rather than by local `try`/`catch`, precisely because a component's render is re-entrant and controlled by React. ## Strategy 1 — an error boundary above the component An error boundary is a component that catches errors thrown while rendering its subtree and renders fallback UI instead. Placed above the component that calls `use`, it turns a rejected data read into a visible, contained failure: ```jsx <ErrorBoundary fallback={<p>Could not load the profile.</p>}> <Suspense fallback={<p>Loading…</p>}> <Profile userPromise={userPromise} /> </Suspense> </ErrorBoundary> ``` The pairing is the point: the Suspense boundary owns "not yet", the error boundary owns "never". Both are decisions made by an ancestor about how much of the UI a missing or failed resource is allowed to take down. If no boundary sits above the component, the error propagates to the root and React unmounts the whole tree rather than leaving a partially rendered UI on screen. That is the harshest failure mode and the reason a data-reading subtree should almost always sit under some boundary. ## Strategy 2 — never reject The alternative is to handle the failure before the promise ever reaches the component, by attaching `.catch()` where the promise is created: ```js const userPromise = fetchUser(id).catch(() => null); ``` Now the promise always fulfills — with `null` on failure — so `use` returns `null` and the component branches on it like any other value. This keeps the failure local and non-destructive, which suits an optional widget where a missing value is acceptable but blanking a whole region is not. The tradeoff is honest: a sentinel value loses the error's detail, and it puts failure handling in the component's normal rendering logic. Reach for it for optional data; reach for a boundary when the failure genuinely means the subtree cannot render. ## Choosing between them Ask what the UI should be when the data is unavailable. If the answer is "this whole region shows an error state", a boundary is the right tool and it also covers every other error in that subtree. If the answer is "render without it", make the promise resolve to a fallback value and let the component decide. Mixing them is fine too: catch to a sentinel for the parts you can degrade, and rely on the boundary for the parts you cannot. ## The misconception to avoid Candidates often assume `use` returns something error-shaped — `null`, `undefined`, or a `[data, error]` pair. It does not. Success returns the value; failure leaves the component entirely. Once that is clear, the reason `try`/`catch` is off the table follows immediately.