try, catch & finally

The safety-net idea

JavaScript normally runs one statement after another. If a statement throws and nothing catches it, the current work stops and the error moves up the call stack. You already practiced reading those messages in Reading error messages, and you saw unwinding in The call stack. This lesson adds the tool that lets your program recover on purpose: try, catch, and finally.

Use try/catch when failure is expected and recoverable: parsing user-provided JSON, reading optional browser storage, or handling a known validation problem. Do not wrap every line “just in case.” A catch block that hides unknown bugs makes debugging harder.

Here is the whole flow in one tiny program. The path array records exactly which blocks run. Change what happens inside try, then step through the recorded run.

1function riskyFormat(text) {2  return text.toUpperCase();3}4 5const path = [];Run6let value = "not set";7 8try {9  path.push("try");10  value = riskyFormat("ok");11} catch (error) {12  path.push("catch " + error.name);13  value = "fallback";14} finally {15  path.push("finally");16}17 18console.log(path.join(" → "));19console.log(value);

1. Success: try runs, catch is skipped, finally runs.
2. Handled error: try begins, a throw jumps to catch, then finally runs.
3. Cleanup: finally is not “after catch.” It is “before leaving this try statement,” whether the path was success, catch, return, or throw.

This is runtime behavior. A SyntaxError can be thrown by JSON.parse at runtime, so a try block can catch it. But a syntax mistake in the same JavaScript file, such as an unclosed brace, prevents the file from being parsed; the try statement is never created.

Most thrown failures you meet are Error objects. Their most useful fields are name, message, and stack. The name is the category, such as TypeError. The message is a human-readable description. The stack is a string showing where the error was created and how calls got there; its exact format varies by browser.

Click the playground instead of trusting a fixed screenshot. It throws real errors in your browser and catches them immediately so you can inspect what this engine produced.

1try {2  JSON.parse("{broken json}");3} catch (error) {4  console.log(error.name);5  console.log(error.message);6  console.log(error.stack?.split("\n")[0]);7  console.log(error instanceof Error);8  console.log(error.cause);9}

Optional catch binding

Sometimes the fact that something failed is enough. If you do not need the thrown value, JavaScript lets you omit the binding name: catch { ... }. This is called optional catch binding.

1try {2  JSON.parse(settingsText);3} catch {4  settings = defaultSettings;5}

That shape is honest when every parse failure gets the same default. If you need to log, inspect error.name, show a specific message, or rethrow unknown failures, use catch (error).

A catch block should handle a specific failure it understands. A small net under the ladder catches first; a bigger net catches what it lets through. In code, that handoff is rethrowing: throw error.

1class ValidationError extends Error {}2 3function saveName(name) {4  try {5    validateName(name);6    return "Saved";7  } catch (error) {8    if (!(error instanceof ValidationError)) {9      throw error;10    }11    return "Please enter a name.";12  }13}

This lesson keeps ValidationError minimal so the pattern is visible. The next lesson, Throwing & custom errors, covers throw, extending Error, and cause in depth.

finally runs while JavaScript is leaving the try statement. That includes normal completion, a caught error, an uncaught error, and a return. The powerful part is also the dangerous part: a return or throw inside finally replaces what was already happening.

1function returnFromTry() {2  try {3    return "try value";4  } finally {5    return "finally value";6  }7}8 9function throwThenFinallyThrows() {10  try {11    throw new TypeError("try failed");12  } finally {13    throw new RangeError("cleanup failed");14  }15}16 17function returnStillCleansUp() {18  const steps = [];19  try {20    steps.push("try");21    return steps.join(" → ");22  } finally {23    steps.push("finally");24    console.log(steps.join(" → "));25  }26}27 28console.log(returnFromTry());Run29try {30  throwThenFinallyThrows();31} catch (error) {32  console.log(error.name + ": " + error.message);33}34console.log(returnStillCleansUp());

What try/catch cannot catch

A catch block protects code that runs while the matching try block is active. Two common surprises fall outside that window.

1try {2  setTimeout(() => {3    try {4      throw new Error("late");5    } catch (error) {6      console.log("callback caught itself");7    }8  }, 0);9} catch (error) {10  console.log("outer catch ran");11}12console.log("try finished");

The code prints try finished, then the callback catches its own Error. Stage 6 covers promises and async/await, where asynchronous error handling gets its own rules.

Where you will use this

The best try/catch blocks are small. Put only the risky operation in try, handle the known failure, and let the rest of the function stay normal.

• Parsing: turn invalid JSON into a default instead of crashing a settings screen.
• Validation: show a friendly message for expected bad input, then rethrow unknown bugs.
• Cleanup: reset UI state in finally after a risky operation finishes.
• Debugging: log name, message, and a stack when you cannot recover locally.

Common misconceptions

Answer once from prediction, then read the explanation even when you were right.

Key takeaways

• try protects runtime work; catch handles a thrown value from that work.
• finally runs before leaving the try statement, even for returns and throws.
• Error objects usually expose name, message, stack, and sometimes cause.
• Use optional catch binding only when you truly ignore the thrown value.
• Rethrow errors your catch block cannot responsibly handle.
• A try block cannot catch syntax mistakes in the same script or errors thrown later in a timer callback.

Up next: Throwing & custom errors.