Error Handling in Web Applications

Robust error handling is what separates a professional web application from a fragile one. It’s not about preventing all errors—that’s impossible—but about managing failures gracefully to maintain user trust and application stability. By implementing a layered strategy, you can catch errors at their source, present helpful feedback, and ensure your development team is alerted to issues before users report them.

The Foundation: Synchronous and Asynchronous Handling

At the core of JavaScript error handling are two fundamental constructs: try...catch for synchronous code and promise-based patterns for asynchronous operations. The try...catch statement allows you to isolate a block of code. If an error is thrown inside the try block, execution immediately stops and transfers to the catch block, where you can handle the exception without crashing the entire program.

try {
  // Code that may fail
  JSON.parse(invalidUserInput);
} catch (error) {
  // Handle the failure gracefully
  console.error("Parsing failed:", error);
  showUserMessage("Please check your input format.");
}

For modern asynchronous code, especially with async/await, you can use try...catch similarly. However, for traditional promise-based APIs, you handle rejections using the .catch() method chained to a promise. Unhandled promise rejections are a major source of silent failures in web apps. Always terminate promise chains with a .catch() to log the error or provide a fallback value.

fetch('/api/data')
  .then(response => response.json())
  .then(data => process(data))
  .catch(error => {
    // Handle any error in the promise chain
    reportErrorToService(error);
    retryFetch();
  });

Containing Component Failures with React Error Boundaries

In a React application, a JavaScript error in the UI can corrupt the entire component tree. React Error Boundaries are a specific React component feature that catches JavaScript errors anywhere in their child component tree. They log those errors and display a fallback UI instead of the component tree that crashed, isolating the failure.

An error boundary is a class component that defines either or both of the lifecycle methods static getDerivedStateFromError() or componentDidCatch(). The first is used to render a fallback UI after an error has been thrown. The second is used for side effects like logging the error to a reporting service.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    logErrorToService(error, errorInfo.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return <h2>Something went wrong displaying this section.</h2>;
    }
    return this.props.children;
  }
}

You can then wrap it around parts of your component tree. A key strategy is to place error boundaries at strategic, high-level locations (like around major route components) to contain failures, while letting the rest of the app remain interactive.

Implementing Global Safety Nets and User Feedback

Not all errors are caught locally. Network failures, third-party library errors, or uncaught exceptions can bubble up. Global error handlers act as a final safety net. In the browser, you can attach listeners to the window object for unhandled errors and unhandled promise rejections.

// Catch synchronous errors
window.onerror = function(message, source, lineno, colno, error) {
  reportErrorToService(error);
  return false; // Prevents default browser error console logging
};

// Catch unhandled promise rejections
window.onunhandledrejection = function(event) {
  reportErrorToService(event.reason);
  event.preventDefault(); // Prevents default browser logging
};

Once an error is caught, how you communicate it to the user is critical. A stack trace is not a user-friendly error page. Instead, design fallback UIs that are helpful and calm. They should acknowledge the problem, suggest a clear action (like "Refresh the page" or "Try again later"), and, if applicable, maintain navigation to other parts of the app. For operational errors (like a failed API call), implementing intelligent retry mechanisms with exponential backoff can often resolve transient issues without user intervention.

Proactive Monitoring with Error Reporting Services

The final layer of a mature error-handling strategy is visibility. You cannot fix what you cannot see. Error reporting services like Sentry, LogRocket, or similar tools are essential. They aggregate errors from your production application, providing rich context like stack traces, user actions, browser state, and release versions.

Integrating such a service typically involves a small SDK installation. You then send captured errors to it from your catch blocks, error boundaries, and global handlers. This enables your team to detect, triage, and prioritize issues quickly, often before a significant number of users are affected. It transforms error handling from a defensive tactic into a proactive quality improvement process.

Common Pitfalls

1. Swallowing Errors Silently: A catch block that only contains console.log(error) or nothing at all is dangerous. While the app doesn't crash, the error is lost, making debugging impossible. Always, at a minimum, log the error to a monitored service. In development, re-throw the error to fail visibly.

// Pitfall try { riskyOperation(); } catch(e) { / silent / }

// Correction try { riskyOperation(); } catch(e) { reportError(e); }

1. Overusing Generic Error Boundaries: Wrapping your entire app in a single error boundary creates a poor user experience—a single error in a minor component blanks the entire screen. Instead, use multiple, strategically placed error boundaries to isolate failures and keep the rest of the UI functional.

1. Ignoring Asynchronous Errors: Forgetting to add .catch() to a promise chain or an await call inside a try block leaves asynchronous errors unhandled. This is a leading cause of "heisenbugs" that are hard to reproduce. Lint rules like @typescript-eslint/no-floating-promises can help catch these omissions.

1. Showing Technical Details to Users: Displaying raw error messages or stack traces in the UI is confusing and a potential security risk. Always map caught errors to generic, helpful user messages. Save the technical details for your error reporting service and developer logs.

Summary

• Layer your defenses: Use try...catch for synchronous logic, .catch() for promises, React Error Boundaries for component failures, and global handlers (window.onerror) as a final safety net.
• Fail gracefully for users: Always replace a broken UI with a helpful, branded fallback message that guides the user towards a next step, such as retrying an action or navigating away.
• Automate recovery where possible: Implement retry logic with backoff for transient failures like network requests to resolve issues without user intervention.
• Never lose visibility: Integrate an error reporting service (e.g., Sentry) to collect, aggregate, and alert on errors from all layers of your application. This is critical for proactive maintenance.
• Isolate failures: Place error boundaries strategically in your React component tree to prevent a single component error from crashing the entire page, preserving the user's context and state elsewhere in the app.