Error Boundaries and Fallback UI

An error boundary catches rendering-related failures in a descendant component tree and replaces the failed subtree with a recoverable fallback UI. It prevents a component error from necessarily taking down the entire surrounding interface.

In React, an error boundary is a component that catches errors thrown during rendering, in lifecycle methods, and in constructors of components below it in the tree. When a boundary catches an error, it can render a fallback instead of the broken subtree.

A fallback UI should clearly communicate that something went wrong and, when practical, provide recovery such as a retry action, navigation elsewhere, or refreshing data. The boundary should be placed around a meaningful part of the interface so one failure does not unnecessarily hide unrelated content.

Error boundaries do not catch every kind of JavaScript error. For example, errors from event handlers and many asynchronous callbacks require their own handling mechanisms rather than relying on an error boundary.

A boundary can also log the captured error for diagnosis while showing a user-friendly message. Good production designs avoid exposing stack traces or implementation details to users.

Key points

• Error boundaries isolate rendering failures to a subtree.
• They render fallback UI when a descendant fails in a boundary-supported phase.
• Fallbacks should provide a clear recovery path when possible.
• Event-handler and asynchronous errors generally need explicit error handling.
• Boundaries can log failures while keeping technical details out of the user interface.

Interview questions

What is an error boundary?

An error boundary is a React component that catches certain errors from components below it in the component tree. Instead of allowing the failed subtree to render normally, it can display fallback UI. This lets unrelated parts of the interface remain available. A boundary can also record the error for debugging.

Why use fallback UI instead of simply letting an error propagate?

Fallback UI gives the user a controlled state when part of the interface cannot render correctly. Without an appropriate boundary, a rendering failure can make a larger portion of the interface unusable. A good fallback explains the problem without exposing implementation details. It can also offer a retry or navigation action.

What kinds of errors are not caught by React error boundaries?

Error boundaries are not a universal replacement for JavaScript error handling. In particular, event-handler errors and many errors occurring asynchronously are not automatically caught by a boundary. Those cases should be handled at the relevant operation or represented through appropriate application state. Knowing the execution context is therefore important when deciding where to handle an error.

Where would you place error boundaries in a frontend application?

I would place boundaries around meaningful independent UI regions rather than automatically using one boundary for everything. For example, a dashboard might isolate its navigation, main content, and optional widgets when those areas can fail independently. The right granularity depends on how much of the interface should remain usable after a failure. I would also consider the recovery action available at each boundary.

How would you design production fallback UI?

I would make the fallback understandable, appropriately scoped, and actionable. The UI should avoid exposing sensitive implementation details while providing a recovery mechanism such as retrying the affected operation or navigating to a stable area. I would pair the boundary with structured error logging and enough context to diagnose failures. I would also monitor whether failures cluster around particular components or releases so the fallback does not become a substitute for fixing systemic defects.