Error handling in JavaScript is something I’ve learned the hard way over the years. When I first started coding, I’d often see my applications crash over small mistakes. It was frustrating for me and even more so for users. Now, I see error handling as a way to make apps strong and reliable. It’s like putting safety nets in place so that when something goes wrong, the app doesn’t fall apart. Instead, it keeps running smoothly or lets users know what happened in a friendly way. In this article, I’ll share seven strategies that have helped me build better JavaScript applications. I’ll include lots of code examples and personal stories to make it easy to understand, even if you’re new to programming.

Let’s start with the basics. Errors are a normal part of coding. They happen when the code tries to do something it can’t, like reading a file that doesn’t exist or working with data that’s in the wrong format. If we don’t handle these errors, the app can stop working completely. That’s why I always plan for errors from the beginning. It makes the app more professional and trustworthy. People rely on software to work, and good error handling shows that you care about their experience.

One of the first things I learned was using try-catch blocks. Think of a try-catch as a safe zone for your code. You put the risky part inside the try block, and if an error occurs, the catch block takes over. This way, the error doesn’t crash the whole program. Instead, you can handle it quietly or show a helpful message. I remember a project where I was parsing user input as JSON. Sometimes, users would type in wrong data, and the app would break. By adding a try-catch, I made it so the app would just ignore the bad data and move on. Here’s a simple example of how I use it.

function readUserInput(input) {
  try {
    let data = JSON.parse(input);
    return data;
  } catch (error) {
    console.log('There was a problem reading the input: ' + error.message);
    return { default: 'value' }; // Give back a safe default
  }
}

let userData = readUserInput('not valid json');
if (userData.default) {
  console.log('Using default data');
}

In this code, if the input isn’t valid JSON, it doesn’t stop the app. It just logs the error and uses a default value. This is a simple way to prevent crashes. I use this all the time when dealing with external data, like from APIs or user forms. It’s a basic tool, but it’s very powerful for keeping things stable.

Another strategy I rely on is creating custom error classes. JavaScript has built-in errors, but sometimes they don’t give enough information. By making my own error types, I can include extra details that help me fix problems faster. For instance, if there’s an error in validating a form, I can make a special error that tells me which field caused the issue. Here’s how I do it.

class LoginError extends Error {
  constructor(username, reason) {
    super(`Login failed for ${username}: ${reason}`);
    this.name = 'LoginError';
    this.username = username;
    this.reason = reason;
    this.time = new Date();
  }
}

function checkLogin(username, password) {
  if (password.length < 6) {
    throw new LoginError(username, 'Password too short');
  }
  // Other checks here
}

try {
  checkLogin('john_doe', '123');
} catch (error) {
  if (error instanceof LoginError) {
    alert(`Please check your password: ${error.reason}`);
  } else {
    console.log('Unexpected error: ' + error);
  }
}

This approach helps me pinpoint issues quickly. In one of my apps, I used custom errors for different parts, like network errors or database errors. It made debugging much easier because I could see exactly what went wrong and where. Plus, it makes the code more organized and easier for others to understand.

When working with asynchronous code, error handling gets a bit trickier. JavaScript often uses promises for tasks that take time, like fetching data from a server. If you don’t handle promise rejections, errors can slip through unnoticed. I’ve had cases where an API call failed, but the app didn’t show any error, leaving users confused. To avoid this, I always use .catch with promises or try-catch with async/await. Here’s an example from a recent project.

async function getWeatherData(city) {
  try {
    let response = await fetch(`https://api.weather.com/${city}`);
    if (!response.ok) {
      throw new Error('Weather data not found');
    }
    let weather = await response.json();
    return weather;
  } catch (error) {
    console.error('Could not get weather: ' + error.message);
    return { temperature: 20, condition: 'unknown' }; // Fallback data
  }
}

getWeatherData('unknown_city')
  .then(data => displayWeather(data))
  .catch(err => console.log('Error in display: ' + err));

In this code, if the city isn’t found, it doesn’t break the app. It just uses default weather data. I like using async/await because it makes the code look cleaner, like regular synchronous code. But you have to remember to handle errors in the catch block. Once, I forgot to add a catch, and it caused silent failures in production. Now, I make it a habit to always include error handling for async operations.

In React applications, errors in one component can bring down the whole page. That’s where error boundaries come in. They are special components that catch errors in their child components and show a fallback UI instead of crashing. I started using these after a component in my app failed and made the entire screen go blank. With error boundaries, I can contain the damage. Here’s a basic setup I use.

class SafeComponent extends React.Component {
  state = { hasError: false };

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

  componentDidCatch(error, info) {
    console.log('Error caught: ' + error + ', details: ' + info.componentStack);
    // You can send this to a service for monitoring
  }

  render() {
    if (this.state.hasError) {
      return <p>This part of the app isn't working right now. Please try again later.</p>;
    }
    return this.props.children;
  }
}

// Wrap any component that might fail
<SafeComponent>
  <MyComponentThatMightBreak />
</SafeComponent>

This way, if MyComponentThatMightBreak has an error, it only affects that part, and the rest of the app stays usable. I’ve used this in forms or dynamic content areas where errors are more likely. It’s a great way to keep the user experience positive even when things go wrong.

Logging errors is another key strategy. If you don’t log errors, you might not even know they’re happening. I set up logging to record errors with details like when they occurred and what the user was doing. This helps me find and fix bugs faster. In the beginning, I’d just use console.log, but now I use more structured logging. Here’s an example of how I do it.

function logError(error, extraInfo = {}) {
  let errorLog = {
    message: error.message,
    stack: error.stack,
    time: new Date().toLocaleString(),
    user: extraInfo.userId || 'unknown',
    action: extraInfo.action || 'general'
  };
  console.error('Error logged:', errorLog);
  // In a real app, send this to a server or service
}

function saveUserData(user) {
  try {
    if (!user.name) {
      throw new Error('User name is missing');
    }
    // Save user logic here
  } catch (error) {
    logError(error, { userId: user.id, action: 'saveUser' });
    alert('Sorry, we couldn't save your data. Please try again.');
  }
}

By logging errors, I can look back and see patterns. For example, if many users have the same error, I know it’s a common issue that needs fixing. I once had a bug that only happened on mobile devices, and logging helped me identify it quickly. It’s like having a diary of what went wrong in your app.

Graceful degradation is about designing your app to work even when parts of it fail. Instead of shutting down, the app continues with reduced features. I think of it as having a backup plan. For instance, if an app can’t load images from a server, it might show placeholder images instead. Here’s a simple example from a web app I built.

async function loadPageContent() {
  try {
    let content = await fetch('/api/content');
    if (!content.ok) throw new Error('Content load failed');
    showContent(await content.json());
  } catch (error) {
    console.warn('Using offline content');
    showOfflineContent(); // Fallback to cached or basic content
  }
}

function showOfflineContent() {
  document.body.innerHTML = '<h1>Welcome</h1><p>You are viewing the basic version.</p>';
}

In this case, if the network request fails, the app still shows something useful. I’ve applied this to features like search or comments. If the search API is down, I might show a message saying “Search is temporarily unavailable” but keep the rest of the site working. Users appreciate when apps don’t just give up on them.

Finally, global error handlers are my last line of defense. They catch errors that weren’t handled anywhere else in the code. I set these up to log errors and prevent the browser from showing scary error messages. It’s like having a safety net for the whole application. Here’s how I implement it.

window.onerror = function(message, source, line, column, error) {
  console.error('Global error: ' + message + ' at ' + source + ':' + line);
  // Send to error reporting service
  return true; // Stop the browser's default error handling
};

window.onunhandledrejection = function(event) {
  console.error('Unhandled promise rejection: ' + event.reason);
  event.preventDefault(); // Prevent default browser behavior
};

I remember a time when an error in a third-party library was causing crashes, and the global handler caught it and logged it so I could fix it. Without this, I might never have known what was wrong. It’s especially important in production apps where users might not report errors.

Putting all these strategies together has made my JavaScript applications much stronger. I start with try-catch for immediate risks, use custom errors for clarity, handle promises carefully, employ error boundaries in React, log everything, plan for degradation, and set global handlers as a backup. Each layer adds more protection. When I look back at my early projects, I see how fragile they were. Now, I build apps that can handle surprises and keep going. It’s not about preventing all errors—that’s impossible—but about managing them well so that users have a smooth experience. I encourage you to try these strategies in your own code. Start small, maybe with try-catch, and gradually add more. You’ll see how much more reliable your apps become.