How Do try/catch/finally Interact?

They interact in a specific order, and knowing the order answers most of the questions people ask about them.

The try block runs first. If it completes without throwing, the catch block is skipped entirely and control moves to the finally block, which always runs. If the try block throws, the catch block runs with the thrown value, and then the finally block runs as well. The finally block runs on every path through the try statement, whether the code succeeded, threw, or returned early.

Two important details. A return inside the try block does not skip the finally block. The return value is calculated, but the finally block still runs before the function actually returns, and if the finally block returns or throws, that wins. And the catch block is optional. A try with a finally and no catch is valid, and it is the right shape for cleanup that has to happen whether or not something went wrong.

There is also the question of what the finally block can do to the outcome. It can swallow an error just by returning normally, which turns a thrown exception into a normal return, and that is worth using deliberately when a failure really is expected and recoverable. It can also replace an error with a different one by throwing from inside it, which is occasionally useful for translating a low level failure into a domain specific one.

A return in the try block does not skip the finally block. The return value is worked out first, but the finally block still runs before the function returns to its caller.

// A return in try still runs finally.
function withFinally() {
  try {
    return "from try";
  } finally {
    console.log("finally ran");
  }
}
console.log(withFinally());   // "finally ran", then "from try"

// An error thrown in finally replaces the original error.
function replaceError() {
  try {
    throw new Error("original");
  } catch (err) {
    console.log("caught:", err.message);
    return "handled";
  } finally {
    console.log("finally still runs");
  }
}
console.log(replaceError());   // "handled"

// A throw inside finally wins over anything else.
function throwInFinally() {
  try {
    return "try value";
  } finally {
    throw new Error("from finally");
  }
}

try {
  throwInFinally();
} catch (err) {
  console.log(err.message);   // "from finally"
}

The last example is the one to remember. The try block returns a value, but the finally block throws, and that throw replaces the pending return entirely. The caller never sees the try value. The same applies to an error that was caught in the catch block: if the finally block throws, the original error is lost, because the finally block is the last thing to run.

This is why a finally block that throws is considered dangerous. Cleanup code that could fail will mask the real problem, and you end up debugging the cleanup rather than the failure. The safe pattern is to wrap the risky cleanup in its own try and catch if you cannot guarantee it will not throw.

There is one more interaction worth knowing. If the finally block returns normally, it swallows any error that was in flight. That is occasionally what you want, for example when you are closing a resource and the close itself failed but you do not want to lose the original failure. But used carelessly it turns a crash into a silent success, which is worse than either outcome.