JavaScript try/catch — Does it catch all errors?

Why This Question Matters

The question is simple: TRUE or FALSE: try/catch can catch all types of JavaScript errors.

If you're just starting out, your instinct is probably to say "True." After all, that's what try/catch is for, right? You wrap your risky code in a block, and if something blows up, the catch block handles it.

But here is the catch (pun intended): JavaScript's execution model is more complex than a simple linear flow. Between the event loop, asynchronous callbacks, and syntax errors, there are plenty of ways for an error to bypass your try/catch block entirely. If you assume try/catch is a universal safety net, you're going to end up with uncaught exceptions that crash your Node.js process or leave your frontend app in a frozen state.

Understanding the Mechanics

To understand why the answer is False, we need to look at how JavaScript actually handles errors.

A try/catch block works on the current call stack. When an error is thrown, JavaScript looks at the current stack to see if there is a handler. If it finds one, it jumps to the catch block. If it doesn't, it bubbles up to the global scope and, if still unhandled, triggers an uncaughtException or a browser console error.

The problem is that not everything happens on the same stack.

Consider a basic setTimeout:

try {
  setTimeout(() => {
    throw new Error("I'm out of reach!");
  }, 100);
} catch (e) {
  console.log("Caught it!"); 
}

In this snippet, the try/catch block finishes executing almost instantly. The setTimeout callback, however, is pushed to the task queue and executed *later*. By the time the error is thrown, the try/catch block is long gone from the call stack. The error is thrown into the void, and your catch block never sees it.

Finding the Correct Answer

The answer is False.

try/catch is great for synchronous code, but it is powerless against:

1. Asynchronous errors: As shown above, callbacks and timers run in a different execution context.
2. Syntax Errors: If you have a typo like const 1var = 10;, the engine fails during the parsing phase. The code never even starts running, so the try/catch block is never entered.
3. Promise Rejections: A rejected promise isn't technically a "thrown error" in the traditional sense. If you don't have a .catch() or an await inside a try/catch, the promise will fail silently or trigger an unhandledRejection.

To catch an async error, you have to be where the error happens:

// This works because we 'await' the promise, 
// bringing the error back into the current stack.
async function fetchData() {
  try {
    const response = await fetch('https://invalid-url.com');
  } catch (e) {
    console.log("Now we actually caught it!");
  }
}

Common Mistakes Developers Make

The most frequent mistake I see is the "Wrap Everything" approach. Developers wrap a massive block of code in one giant try/catch and assume they're safe.

The danger here is twofold. First, as we've established, it doesn't catch async bugs. Second, it masks where the error actually happened. If you wrap 100 lines of code in one block, you lose the granularity of knowing *which* operation failed.

Another common trap is forgetting that async functions return promises. If you call an async function without await, the try/catch surrounding the call is useless:

async function risky() {
  throw new Error("Boom");
}
try {

  risky(); // Missing 'await' here!

} catch (e) {

  // This block will NEVER execute

}

Real-World Usage

In a production environment, relying solely on try/catch is a recipe for disaster. Senior engineers usually implement a multi-layered error handling strategy.

In Node.js, we use process.on('unhandledRejection', ...) and process.on('uncaughtException', ...) as a last line of defense. These don't "fix" the error, but they allow the app to log the failure and restart gracefully instead of just vanishing.

In React, we use Error Boundaries. Since a crash in one component can unmount the entire component tree, Error Boundaries act as a "catch" for the UI layer, allowing us to show a fallback "Something went wrong" page instead of a white screen.

For API calls, the standard is to use async/await with localized try/catch blocks or a wrapper utility that returns a tuple (like [error, data]), which avoids the deep nesting of catch blocks.

Key Takeaways