How Things Work

Error Boundary

React component tree mein errors pakadta hai aur fallback UI dikhata hai.

How It Works

Error boundaries aise React class components hain jo apne child component tree mein kahin bhi JavaScript errors pakdte hain, unhe log karte hain, aur puri application crash karne ki jagah fallback UI display karte hain. Woh JavaScript ke catch{'} block ki tarah kaam karte hain, lekin component tree ke liye. Ek error boundary rendering ke dauran, lifecycle methods mein, aur poore neeche ke tree ke constructors mein errors pakdta hai.

Ek child component render ke dauran error throw karta hai

Jab subtree mein koi bhi component rendering ke dauran (ya lifecycle method mein) throw karta hai, React error ko fiber tree se upar propagate karna shuru karta hai, nearest error boundary dhundhta hua.

React fiber tree unwind karta hai boundary dhundh ne ke liye

React parent fibers se upar traverse karta hai. Agar use koi class component milta hai jo getDerivedStateFromError ya componentDidCatch implement karta hai, woh wahan ruk jaata hai. Agar woh koi nahi milne par root tak pahunch jaata hai, poori app unmount ho jaati hai.

getDerivedStateFromError boundary state update karta hai

React boundary class par getDerivedStateFromError(error) call karta hai. Yeh static method new state return karta hai (jaise '{' hasError: true '}') jo boundary ko fallback UI ke saath re-render karata hai.

componentDidCatch error log karta hai

Fallback UI dikhane ke baad, React componentDidCatch(error, errorInfo) call karta hai — Sentry jaise logging service ko error bhejna ke liye acchi jagah.

Error boundary fallback UI render karta hai

Boundary component apni state (hasError) check karta hai aur ya toh children (normal) ya fallback JSX element render karta hai. Boundary ke bahar baaki app normally kaam karti rehti hai.

Key Concepts

🛡️getDerivedStateFromError

Static class method. Render phase ke dauran call hota hai jab child throw karta hai. Fallback rendering trigger karne ke liye new state return karta hai.

📊componentDidCatch

Instance method. Commit phase ke dauran call hota hai fallback render hone ke baad. Error logging ke liye use karo. Error + component stack receive karta hai.

⬆️Error Propagation

Errors fiber tree se nearest boundary tak bubble karte hain, bilkul jaise exceptions call stacks se bubble karte hain.

🔄Recovery / Reset

Boundaries ko unka key prop change karke reset kiya ja sakta hai, jo React ko poori subtree fresh unmount aur remount karaata hai.

Error Boundary implement karna

tsx

1class ErrorBoundary extends React.Component {
2  state = { hasError: false, error: null };
3
4  static getDerivedStateFromError(error) {
5    // Called during render — must be pure, no side effects
6    return { hasError: true, error };
7  }
8
9  componentDidCatch(error, info) {
10    // Called after commit — safe for side effects like logging
11    logErrorToSentry(error, info.componentStack);
12  }
13
14  render() {
15    if (this.state.hasError) {
16      return <FallbackUI error={this.state.error} />;
17    }
18    return this.props.children;
19  }
20}
21
22// Usage:
23<ErrorBoundary>
24  <MyComponent /> {/* If this throws, ErrorBoundary catches it */}
25</ErrorBoundary>

💡

Why This Matters

Error boundaries ke bina, ek single unhandled render error aapki poori React app crash kar deta hai aur blank screen dikhata hai. Error boundaries aapko failures ko UI ke isolated sections mein quarantine karne dete hain — app ka baaki hissa kaam karta rehta hai. Yeh production apps ke liye critical hai jahan aap har edge case predict nahi kar sakte.

Common Pitfalls

⚠Error boundaries event handlers mein errors NAHI pakdte (wahan try/catch use karo), async code (setTimeout, Promises), ya server-side rendering mein.

⚠Error boundaries class components hone chahiye — koi hook equivalent nahi hai. Hook-friendly wrapper ke liye 'react-error-boundary' library use karo.

⚠Ek error boundary apne khud ke errors nahi pakad sakta — sirf apne children ke errors. Boundaries ko hamesha doosri boundary se wrap karo.

Real-World Use Cases

1Production Error Reporting with Sentry Integration

Scenario

Your e-commerce app crashes in production when a product with malformed data renders. The entire page goes white and users see nothing — you lose the sale and have no visibility into what happened.

Problem

Without error boundaries, a single component throwing an error unmounts the ENTIRE React tree. The user sees a blank page. No error tracking fires because the crash happened during rendering, not in a try/catch block.

Solution

Wrap critical sections in error boundaries with strategic granularity: one around the product card, one around the cart, one around the whole page. Use componentDidCatch to send the error + componentStack to Sentry. Show a helpful fallback UI ('Something went wrong, refresh to try again') instead of a blank page.

💡

Takeaway: Error boundaries are your PRODUCTION safety net. Place them at route level (catch everything), feature level (isolate failures), and widget level (for third-party components you don't control). Always log to an error tracking service in componentDidCatch.

2Graceful Degradation for Third-Party Widgets

Scenario

You embed a third-party analytics chart widget in your dashboard. After a library update, the widget occasionally throws during rendering due to unexpected data formats.

Problem

The chart crash cascades — it's nested inside your dashboard layout, so the error propagates up and takes down the entire dashboard, including the navigation, sidebar, and all other widgets.

Solution

Wrap ONLY the third-party widget in its own error boundary. The fallback shows a placeholder ('Chart unavailable — refresh to retry'). The rest of the dashboard remains fully functional. Users can still use all other features while you investigate the chart issue.

💡

Takeaway: Error boundaries give you component-level fault isolation, similar to microservice circuit breakers. Treat each third-party or unstable component as an isolated fault domain.

Join the discussion

Comments

Loading comments...

Cookie preferences

We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.