Error Boundary Lifecycle

Error boundaries catch certain errors thrown during rendering and related React lifecycle work in descendant components, then can render fallback UI. A class error boundary typically uses `static getDerivedStateFromError` to update state and `componentDidCatch` to perform side effects such as logging.

An error boundary is a React class component that defines how a subtree responds when a descendant throws an error during rendering. The boundary itself does not catch errors thrown by its own rendering logic; it protects the components below it in the tree.

When a descendant throws, React can call `getDerivedStateFromError(error)`. This method should be a pure state transition: it returns state that causes the boundary to render fallback UI, or returns `null` when no state update is needed. It does not receive responsibility for logging or other side effects.

React can then invoke `componentDidCatch(error, errorInfo)` on the boundary. This lifecycle method is appropriate for side effects such as reporting the error to an observability service. `errorInfo` contains additional information about the component tree involved in the failure.

A common pattern is to keep an `hasError` flag in state, return a fallback from `render` when that flag is true, and use `componentDidCatch` for logging. Error boundaries can be nested, allowing different parts of an application to have different fallback behavior.

Error boundaries do not catch every kind of JavaScript error. In particular, they do not replace ordinary handling for event-handler errors, asynchronous callbacks such as a later `setTimeout`, server-side rendering failures, or errors thrown by the boundary itself.

Key points

• `getDerivedStateFromError` updates state so fallback UI can render.
• `componentDidCatch` is used for side effects such as error reporting.
• A boundary catches errors from descendant components, not errors in the boundary itself.
• Error boundaries do not catch ordinary event-handler or asynchronous callback errors.
• Nested boundaries can isolate failures to smaller portions of the UI.

Interview questions

What is the difference between `getDerivedStateFromError` and `componentDidCatch`?

`getDerivedStateFromError` runs when React handles an error and lets the boundary derive state for fallback rendering. It should remain free of side effects. `componentDidCatch` is the place for side effects such as sending an error report to a monitoring system, and it receives the error plus component-stack information.

What is an error boundary in React?

An error boundary is a class component that catches certain errors from components below it in the React tree. It can update its state and render fallback UI instead of allowing the affected subtree to fail normally. The boundary commonly uses `getDerivedStateFromError` for the state transition and `componentDidCatch` for logging or other side effects.

What errors are not caught by an error boundary?

Error boundaries do not catch errors thrown in event handlers or in asynchronous callbacks such as timers. They also do not handle server-side rendering failures and do not protect against errors thrown by the boundary itself. Those cases require their own error-handling mechanisms.

Why might an application use multiple error boundaries?

Multiple boundaries let an application isolate failures to meaningful sections of the UI. For example, a failure in one dashboard panel does not necessarily need to replace the entire page with a global fallback. Boundaries can therefore provide different recovery or messaging behavior for different subtrees.

How would you design error reporting with an error boundary?

I would use `componentDidCatch` to send structured error information to an observability service. The report should include the exception and useful component-stack context while avoiding sensitive user data. The boundary would independently manage fallback state so logging failures do not become the mechanism for deciding whether fallback UI renders.