JavaScript Error Handling: A Practical Guide to try, catch, and throw

Errors are a natural part of software development. No matter how carefully you write code, things will go wrong—users will enter unexpected input, network requests will fail, and edge cases will surface that you didn't anticipate. The question isn't whether errors will occur, but how your code handles them when they do. JavaScript provides robust error handling mechanisms that let you catch problems, respond gracefully, and debug issues effectively.

What Errors Are in JavaScript

In JavaScript, an error is an object that represents something that went wrong during code execution. When an error occurs, JavaScript stops executing the current code and creates an error object containing information about what happened. This object includes a message describing the problem, a name identifying the error type, and optionally a stack trace showing where in your code the error occurred.

JavaScript has several built-in error types that represent different categories of problems. SyntaxError occurs when you write invalid JavaScript syntax—usually caught by the parser before the code runs. TypeError happens when an operation can't be performed on a value of the wrong type, like trying to call a non-function or accessing a property on null. ReferenceError occurs when you try to use a variable that doesn't exist, and RangeError happens when a value is outside an expected range.

Consider this runtime error that occurs when trying to access a property on something that doesn't exist:

const user = null;
console.log(user.name);
// TypeError: Cannot read property 'name' of null

Or this one when using an undefined variable:

console.log(madeUpVariable);
// ReferenceError: madeUpVariable is not defined

These errors represent situations where JavaScript cannot continue executing your code. Without proper handling, an error crashes your program or leaves it in an inconsistent state. With error handling, you can catch the problem, respond appropriately, and keep your application running.

Using try and catch Blocks

The try...catch statement is the foundation of JavaScript error handling. Code that might throw an error goes inside the try block, and if an error occurs, the catch block handles it. This separates your normal logic from your error handling logic, making code cleaner and more maintainable.

try {
  // Code that might throw an error
  const data = JSON.parse(userInput);
  console.log("Parsed successfully:", data);
} catch (error) {
  // Code that runs if an error occurred
  console.log("Failed to parse:", error.message);
}

When JSON.parse() encounters invalid JSON, it throws a SyntaxError. Without the try-catch, this would crash your program. With it, the error is caught, and your catch block handles it gracefully.

The error object passed to the catch block contains useful information. The message property provides a human-readable description of what went wrong. The name property identifies the type of error. The stack property contains a string describing the call stack at the moment the error was thrown—this is invaluable for debugging:

try {
  riskyOperation();
} catch (error) {
  console.log("Error name:", error.name);    // "TypeError"
  console.log("Error message:", error.message);  // Actual error message
  console.log("Stack trace:", error.stack);  // Where the error occurred
}

You can nest try-catch blocks to handle errors at different levels:

try {
  // Outer try - catches errors from any of this
  connectToDatabase();
  try {
    // Inner try - more specific handling
    fetchUserData();
  } catch (innerError) {
    console.log("Failed to fetch user:", innerError.message);
    throw innerError;  // Re-throw to let outer catch handle it
  }
} catch (outerError) {
  console.log("Database or user operation failed:", outerError.message);
}

The finally Block

The finally block runs after the try and catch blocks, regardless of whether an error occurred. This makes it perfect for cleanup tasks—closing files, releasing resources, or resetting state—that should happen whether the operation succeeded or failed.

let connection;

try {
  connection = openDatabase();
  const data = connection.query("SELECT * FROM users");
  console.log("Data fetched:", data);
} catch (error) {
  console.log("Database error:", error.message);
} finally {
  // This always runs - even if there's an error
  if (connection) {
    connection.close();
    console.log("Database connection closed");
  }
}

The finally block executes even if the catch block re-throws the error, or if the try block contains a return statement. This ensures your cleanup code always runs:

function processFile(filename) {
  let file;

  try {
    file = openFile(filename);
    const content = readFile(file);
    return JSON.parse(content);  // Early return
  } catch (error) {
    console.log("Failed to process file:", error.message);
    return null;
  } finally {
    // This runs even after the return statement
    if (file) {
      closeFile(file);
    }
  }
}

A common pattern is to use finally to reset UI state that you set in the try block:

async function loadUserProfile(userId) {
  showLoadingSpinner();

  try {
    const response = await fetch(`/api/users/${userId}`);
    const user = await response.json();
    displayProfile(user);
  } catch (error) {
    showError("Failed to load profile");
  } finally {
    hideLoadingSpinner();  // Always hide the spinner
  }
}

The loading spinner is shown before the try block, and finally ensures it hides whether the fetch succeeded or failed.

Throwing Custom Errors

While JavaScript has built-in error types, you'll often want to create your own errors that better describe your specific situation. The throw statement lets you create and throw custom errors:

function divide(a, b) {
  if (typeof a !== 'number' || typeof b !== 'number') {
    throw new Error('Both arguments must be numbers');
  }

  if (b === 0) {
    throw new Error('Cannot divide by zero');
  }

  return a / b;
}

When you throw an error, it's like JavaScript saying "something went wrong here" and creating an error object. The throw statement stops execution and looks for the nearest try-catch block to handle it.

You can throw any value, not just Error objects, but throwing Error instances is strongly recommended because they provide consistent error information:

// Throwing a plain string (not recommended)
throw "Something went wrong";

// Throwing an Error object (recommended)
throw new Error("Something went wrong");

For more specific error handling, you can create custom error classes that extend the built-in Error class:

class ValidationError extends Error {
  constructor(message, field) {
    super(message);
    this.name = "ValidationError";
    this.field = field;
  }
}

function validateUser(user) {
  if (!user.email) {
    throw new ValidationError("Email is required", "email");
  }

  if (!user.email.includes("@")) {
    throw new ValidationError("Invalid email format", "email");
  }

  if (!user.age || user.age < 0) {
    throw new ValidationError("Age must be a positive number", "age");
  }
}

// Using the custom error
try {
  validateUser({ email: "invalid", age: -5 });
} catch (error) {
  if (error instanceof ValidationError) {
    console.log(`Validation error in field '${error.field}': ${error.message}`);
  } else {
    throw error;  // Re-throw non-validation errors
  }
}

Custom error classes let you distinguish between different error types and include relevant metadata. A ValidationError includes the field name, a DatabaseError might include the query that failed, and a NetworkError might include the URL that couldn't be reached.

Why Error Handling Matters

Good error handling transforms chaotic failures into predictable, manageable behavior. Instead of your application crashing in ways users don't understand, you can provide meaningful feedback, log diagnostic information, and gracefully degrade functionality when something goes wrong.

Graceful Failure

Graceful failure means your application continues running even when something unexpected happens. Consider a chat application where one message fails to send:

async function sendMessage(message) {
  try {
    await api.sendMessage(message);
    showSuccess("Message sent!");
  } catch (error) {
    showError("Failed to send message. Will retry automatically.");
    // The app continues working - users can try again
  }
}

Without this try-catch, a failed message send would crash the entire chat interface. With it, users get feedback and can continue using other features. The same principle applies to displaying images when a CDN is slow, falling back to cached data when an API is down, or disabling a form button when a required service is unavailable.

Graceful degradation isn't just about user experience—it's about system resilience. An unhandled error in one part of your application can cascade into failures in unrelated parts. Proper error handling isolates problems and prevents them from taking down your entire system.

Debugging Benefits

Error handling provides invaluable information for debugging. When you log error details—message, type, stack trace—you create a trail that leads you directly to the problem. Without this, you'd be left guessing why something failed or trying to reproduce issues that are hard to trigger.

try {
  processOrder(orderData);
} catch (error) {
  console.error("Order processing failed:", {
    timestamp: new Date().toISOString(),
    orderId: orderData.id,
    errorName: error.name,
    errorMessage: error.message,
    stackTrace: error.stack
  });

  // Alert monitoring system
  notifyMonitoringService({
    severity: "high",
    message: error.message,
    context: { orderId: orderData.id }
  });
}

Structured error logging with contextual information makes debugging much faster. The order ID tells you exactly which order failed, the timestamp tells you when, and the stack trace shows where in the code the error occurred.

User Experience

Users don't want to see technical error messages or blank screens. Good error handling lets you show users helpful, non-technical messages that explain what happened and what they can do about it:

try {
  await saveDocument();
} catch (error) {
  if (error.message === "Network connection lost") {
    showMessage("You're offline. Your changes are saved locally and will sync when you're back online.");
  } else if (error.message === "Storage full") {
    showMessage("Your storage is full. Please delete some documents to continue saving.");
  } else {
    showMessage("Failed to save. Please try again in a moment.");
  }
}

Each message tells users what happened and what they should do next. This transforms a frustrating failure into a manageable situation.

Practical Error Handling Patterns

Let's walk through common patterns you'll encounter in real applications.

Async/Await Error Handling

When using async/await, errors are thrown as exceptions just like in synchronous code. This makes error handling straightforward but requires careful use of try-catch:

async function fetchUserData(userId) {
  try {
    const response = await fetch(`/api/users/${userId}`);

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    const data = await response.json();
    return data;
  } catch (error) {
    console.error("Failed to fetch user:", error.message);
    return null;  // Or throw a custom error, or show UI message
  }
}

A common pattern is to wrap multiple async operations in a single try-catch:

async function initializeApp() {
  try {
    const [user, settings, notifications] = await Promise.all([
      fetchCurrentUser(),
      fetchUserSettings(),
      fetchNotifications()
    ]);

    displayUser(user);
    applySettings(settings);
    showNotifications(notifications);
  } catch (error) {
    console.error("App initialization failed:", error.message);
    showCriticalError("Failed to load application. Please refresh the page.");
  }
}

If any of the three fetches fail, the entire initialization fails together, and you show a single error message instead of three separate ones.

Error Handling in Loops

When processing multiple items where each might fail, decide whether one failure should stop everything or continue with the others:

// Option 1: Stop on first error
async function processAllItems(items) {
  for (const item of items) {
    try {
      await processItem(item);
    } catch (error) {
      console.error(`Failed to process item ${item.id}:`, error.message);
      throw error;  // Stop processing
    }
  }
}

// Option 2: Continue despite errors
async function processAllItems(items) {
  const results = [];
  const errors = [];

  for (const item of items) {
    try {
      const result = await processItem(item);
      results.push({ item, success: true, result });
    } catch (error) {
      errors.push({ item, success: false, error: error.message });
    }
  }

  if (errors.length > 0) {
    console.warn(`${errors.length} items failed to process`);
  }

  return { successful: results, failed: errors };
}

Choose the pattern that matches your requirements. Stopping on error makes sense for critical operations that depend on order. Continuing despite errors makes sense for batch processing where you want to complete as much work as possible.

Cleanup with finally

The finally block is essential for guaranteed cleanup:

async function runBackgroundTask() {
  let lock;

  try {
    lock = await acquireLock("exclusive-access");
    await performLongRunningOperation();
  } finally {
    if (lock) {
      await releaseLock(lock);
    }
  }
}

No matter what happens during the operation—whether it completes successfully or throws an error—the lock gets released.

Suggestions for Better Error Handling

Catch specific errors, not just any error. Different errors require different handling:

try {
  const data = JSON.parse(userInput);
} catch (error) {
  if (error instanceof SyntaxError) {
    showValidationError("Invalid JSON format");
  } else {
    // Something else went wrong
    console.error("Unexpected error:", error);
  }
}

Don't swallow errors silently. At minimum, log that an error occurred:

// Bad - error disappears silently
try {
  riskyOperation();
} catch (error) {
  // Do nothing
}

// Better - at least log it
try {
  riskyOperation();
} catch (error) {
  console.error("Operation failed:", error);
}

// Best - handle it appropriately
try {
  riskyOperation();
} catch (error) {
  notifyErrorMonitoring(error);
  showUserFriendlyMessage(error);
}

Provide context when re-throwing. If you catch an error and want to re-throw it with more context:

try {
  await saveUserData(user);
} catch (error) {
  throw new Error(`Failed to save user ${user.id}: ${error.message}`);
}

Use error boundaries in user interfaces. For UI components that can fail, catch errors at the boundary and show fallback UI:

function UserProfile({ userId }) {
  try {
    const user = fetchUser(userId);
    return <Profile user={user} />;
  } catch (error) {
    return <ErrorMessage message="Failed to load profile" onRetry={retry} />;
  }
}

Let high-level code handle errors. Don't catch errors at every level of your application. Let them bubble up to a level that knows how to handle them:

// Low-level function - don't handle the error here
function parseJSON(jsonString) {
  return JSON.parse(jsonString);  // Let errors propagate
}

// High-level function - handle the error here
function loadUserSettings() {
  const json = readFileSync("settings.json");
  return parseJSON(json);  // Errors from parseJSON will bubble up to this level
}

Conclusion

Error handling isn't optional—it's essential for building robust applications. When you use try-catch-finally blocks and throw custom errors, you transform unpredictable failures into manageable situations that keep your application running, provide helpful feedback to users, and give you the information you need to debug problems.

The key principles are straightforward: wrap risky code in try blocks, catch specific errors rather than catching everything, use finally for cleanup that must always run, and throw custom errors with meaningful context when something goes wrong in your application logic.

Good error handling makes the difference between applications that crash mysteriously and applications that degrade gracefully, log useful diagnostic information, and keep users informed when things don't go as expected. Start handling errors properly today, and you'll save yourself countless hours of debugging tomorrow.