Common questions about error boundaries in React 18+, answered with react-crash-guard.
No. React error boundaries only catch errors thrown during the render phase,
lifecycle methods, and constructors. Errors thrown inside useEffect
callbacks, setTimeout, event handlers, or promise rejections escape
the boundary entirely. react-crash-guard bridges these with the
useErrorHandler hook, which stores the error in state and rethrows it
during render so the nearest boundary catches it.
Pass a function fallback to the boundary and call the reset callback it
receives: fallback={(error, reset) => ...}. Inside a fallback, the
useErrorRecovery hook also exposes retry,
retryCount, and isRecovering, plus an optional retry delay
and a maximum retry count that prevents infinite re-render loops.
react-error-boundary is a minimal primitive: one generic
ErrorBoundary component plus a useErrorBoundary hook for async
errors. react-crash-guard is the batteries-included option, adding four
purpose-built boundaries (global, route, feature, async), a pluggable
ErrorReporter interface with Sentry and AWS CloudWatch implementations
included, automatic boundary/route/feature context on every report, and a
classifyError utility that labels errors as network, chunk-load,
permission, render, or unknown so the fallback UI can react appropriately. Both have
zero runtime dependencies and can coexist in the same app.
React only supports the error boundary lifecycle
(getDerivedStateFromError and componentDidCatch) on class
components, so a boundary itself cannot be a hook. react-crash-guard
keeps a single internal class component and exposes function components and hooks
around it, so application code never writes a class.