Error Boundaries were introduced in React 16 to help developers gracefully handle JavaScript errors within React applications.
An error boundary is a special type of React component that catches errors in its child component tree, logs those errors, and renders a fallback UI instead of allowing the entire app to crash. These boundaries can capture errors that occur during rendering, inside lifecycle methods, and within constructors of child components.
That said, Error Boundaries do not catch errors that happen in the following situations:
Event handlers
Asynchronous operations (such as
setTimeoutorrequestAnimationFrame)Server-side rendering
Errors thrown inside the error boundary itself
In short, error boundaries are designed to handle errors that occur during the React rendering process, not general JavaScript runtime issues.
A basic Error Boundary component typically looks like this:
Once created, this component can be wrapped around any part of your application where you want error protection.
How Error Boundaries Work
The key piece in an Error Boundary is the getDerivedStateFromError lifecycle method. This method is triggered when a child component throws an error. It receives the error as an argument and returns an updated state.
When an error occurs, getDerivedStateFromError sets a state value (for example, hasError) to true. The component then re-renders and displays a fallback UI instead of the broken component tree—preventing users from seeing a blank or crashed page.
Using Error Boundaries with Error Tracking Tools
If your project uses an error monitoring or issue tracking service, Error Boundaries integrate nicely through the componentDidCatch lifecycle method.
This method is called after an error is thrown and provides two parameters:
error – the actual error object
info – an object containing a
componentStackthat shows where the error originated
Here’s how componentDidCatch can be added to your Error Boundary:
While it may be tempting to update state inside componentDidCatch, React advises against it. According to the official documentation:
“Rendering fallback UI using
setStateinsidecomponentDidCatchwill be deprecated in the future. Instead, usestatic getDerivedStateFromError().”
By combining getDerivedStateFromError for UI fallback and componentDidCatch for logging, you get the best of both worlds.
Placing an Error Boundary at the root level of your application ensures that most runtime errors are caught and properly reported.
Why Error Boundaries Matter
Modern React applications often consist of deeply nested component trees. When an error occurs, identifying the exact source can be difficult and time-consuming.
Error Boundaries help surface these issues clearly by isolating failures and pointing directly to the component where the problem occurred—making debugging faster and improving user experience.
Bonus Tip: Use TypeScript
TypeScript enhances JavaScript with static typing, allowing you to catch many errors during development rather than at runtime. When used correctly, it significantly reduces bugs in production.
However, TypeScript is not a replacement for Error Boundaries. Unexpected API responses or unhandled edge cases can still break your UI. In such scenarios, a well-designed fallback UI ensures your users aren’t left staring at a broken page.
Bonus #2: Sentry Error Boundary
If you’re using Sentry, it already provides a built-in ErrorBoundary component. You can use it directly or explore similar solutions offered by other monitoring tools.
No matter which tool you choose, implementing Error Boundaries adds a critical safety net to your React application.
