FrontendInterviews.dev

Error Handling & Resilience

Building fault-tolerant frontend applications with proper error handling, retry strategies, and graceful degradation.

Quick Navigation: Error Boundaries • Retry Strategies • Fallback UI • Recovery Patterns

Why Error Handling Matters

  • Network failures: API calls fail, connections drop
  • User errors: Invalid input, expired sessions
  • Runtime errors: JavaScript exceptions, null references
  • Third-party failures: CDN issues, external API downtime

Error Boundaries

React error boundaries catch JavaScript errors in child components and display fallback UI.

Advantages

  • ✓Isolate failures: One component crash doesn't break entire app
  • ✓Graceful degradation: Show fallback instead of white screen
  • ✓Error reporting: Log errors to monitoring service

Limitations

  • ✗Only runtime errors: Doesn't catch async or event handler errors
  • ✗Class components only: Must use class syntax
  • ✗No SSR: Doesn't work during server rendering

Placement Strategy

  • App level: Catch-all for unexpected errors
  • Route level: Isolate page failures
  • Feature level: Isolate specific features (comments, sidebar)
  • Widget level: Most granular, each component has own boundary

💡 Trade-off: More boundaries = better isolation but more fallback UI to maintain

Retry Strategies

Immediate Retry

Retry immediately on failure.

Pros

  • ✓ Fast recovery from transient errors
  • ✓ Simple to implement

Cons

  • ✗ Can overwhelm failing server
  • ✗ Wastes resources if persistent failure

Exponential Backoff

Wait 1s, 2s, 4s, 8s... between retries.

Pros

  • ✓ Prevents thundering herd
  • ✓ Gives server time to recover
  • ✓ Industry standard

Cons

  • ✗ Slower recovery
  • ✗ Poor UX for user-triggered actions

Exponential Backoff with Jitter

Add randomness to prevent synchronized retries.

✅ Recommended: Best practice for distributed systems

Circuit Breaker

Stop retrying after too many failures, wait before trying again.

C
Closed: Normal operation, requests flow through
O
Open: Failures exceeded threshold, fail fast
H
Half-Open: Allow one request to test recovery

Fallback UI Patterns

Error Message

Show clear error message with action options.

  • • Be specific about what went wrong
  • • Offer "Retry" button for transient errors
  • • Provide contact support option for persistent errors
  • • Avoid technical jargon

Cached/Stale Data

Show last known good data with stale indicator.

Pros: Better UX than empty state
Cons: May show outdated info

Skeleton/Placeholder

Show loading skeleton while retrying.

Pros: Users know content is loading
Cons: Infinite loading if not handled

Reduced Functionality

Disable failed feature, keep rest of app working.

🎯 Best For: Non-critical features (analytics, recommendations)

Error Recovery Patterns

Optimistic with Rollback

Update UI immediately, rollback on failure.

1
User clicks "Like" → UI shows liked immediately
2
API call in background
3
On failure → Rollback UI + Show error toast

Queue and Sync Later

Store actions locally, sync when connection restored.

  • • Great for offline-first apps
  • • Use IndexedDB or localStorage for queue
  • • Handle conflicts on sync

User-Triggered Retry

Let user decide when to retry.

  • • Clear "Try Again" button
  • • Preserve user input on form errors
  • • Show what will be retried

Best Practices

  • 1.Categorize errors. Handle network, auth, validation differently.
  • 2.Log everything. Send errors to monitoring (Sentry, LogRocket).
  • 3.User-friendly messages. "Something went wrong" is not helpful.
  • 4.Preserve user data. Never lose form input on errors.
  • 5.Test error states. Mock failures in development.
Previous
Component Architecture Patterns
Complete & Next
Authentication & Authorization Guide