Error Logging with componentDidCatch

In React class error boundaries, `componentDidCatch` receives an error and information about the component tree where the error occurred. That information can be normalized and forwarded to an error-monitoring or logging service.

An error boundary is a class component that implements `componentDidCatch` and typically `static getDerivedStateFromError`. The boundary catches errors thrown during rendering and certain lifecycle methods or constructors in its descendant tree, allowing the UI to show a fallback instead of unmounting the affected subtree.

`componentDidCatch(error, errorInfo)` is primarily useful for side effects such as logging. The `error` argument is the thrown exception, while `errorInfo` contains React-specific diagnostic information, notably the component stack. The component stack helps identify which React components were involved in the failing render path.

A production application can transform these values into a monitoring event containing fields such as the error message, stack, component stack, route, release identifier, and relevant application metadata. The logging operation should not itself prevent the fallback UI from rendering, so monitoring integrations should handle failures defensively.

Error boundaries do not catch every possible JavaScript failure. For example, they do not replace handling for event-handler exceptions, asynchronous callbacks such as arbitrary `setTimeout` work, server-side rendering failures, or errors thrown by the boundary itself. Those cases generally require separate error-handling mechanisms.

Key points

• `componentDidCatch(error, errorInfo)` is a side-effect hook for class-based error boundaries.
• `error` represents the thrown exception; `errorInfo.componentStack` provides React component-stack diagnostics.
• Monitoring services can receive both JavaScript and React-specific context.
• Use a fallback state mechanism such as `getDerivedStateFromError` for the user-facing recovery UI.
• Error boundaries have defined limits and do not catch every asynchronous or event-handler error.

Interview questions

What information does `componentDidCatch` receive?

It receives the thrown `error` and an `errorInfo` object. The error contains the exception itself, while `errorInfo.componentStack` gives React-specific information about the component tree involved. That component stack is particularly useful when sending an event to a monitoring service.

How would you use an error boundary for production error monitoring?

I would put a class error boundary around an appropriate UI subtree and implement `componentDidCatch`. I would normalize the error and `errorInfo`, then send them to the monitoring service along with useful non-sensitive context such as the route and application release. I would separately implement fallback rendering so users get a recoverable UI while the event is reported.

What errors are not caught by React error boundaries?

Error boundaries are not a universal JavaScript exception handler. They do not catch errors from event handlers, asynchronous callbacks such as timers or promise work, server-side rendering, or errors thrown by the boundary itself. Those situations require mechanisms appropriate to where the failure occurs, such as local `try/catch` handling or promise rejection handling.

Why might the component stack be valuable when the JavaScript stack already exists?

The JavaScript stack identifies the execution path through JavaScript functions, but it does not necessarily explain the React component hierarchy that produced the failure. The component stack adds framework-level context about the rendered component tree. Combining both gives monitoring systems more actionable information for locating the affected UI.