Module failure_panel 

A region of a window whose contents the host could not produce.

This is not an error boundary, and is not called one

A JavaScript error boundary catches an exception thrown while a subtree renders and swaps in a fallback. Nothing here can do that, and the name ErrorBoundary would promise it. What was established about GPUI at the pinned revision:

• Render::render and RenderOnce::render return impl IntoElement. There is no fallible render, no Result, and therefore no failure a parent could observe as a value coming back from a child.
• GPUI calls panic::catch_unwind in exactly one place, its own #[gpui::test] harness. Nothing on the platform draw path catches anything, so a panic in render unwinds straight out of Window::draw.
• It cannot simply be wrapped, either. A draw holds an element-arena scope guard whose exit hands back a clear token the caller owes, the arena itself hands out raw pointers into a bump allocation, and the window asserts its rendered-entity stack is empty around every draw. Unwinding past that leaves the window’s own bookkeeping in a state the next frame does not expect. On top of which &mut Window and &mut App are not unwind-safe, so reaching for catch_unwind would mean asserting they were — which is precisely the claim the panic just disproved.

So a render panic is not catchable here in any way worth shipping, and this component does not pretend to catch one. It is for the ordinary case that actually happens: the host already holds a failure value. It asked for something and got an Err, a refusal, a timeout, a document it could not parse. FailurePanel::from_result is the whole seam.

What it guarantees is the part that matters either way: the failure stays on screen in the host’s own words, a retry belongs to the host, and a panel that failed is never drawn as a panel that is empty.

Structs

FailurePanel

A panel that states what went wrong instead of what it was going to show.