Finally Block in JavaScript Error Handling Guide

The finally block is the part of try...catch that always runs, no matter what. If the try block succeeds, finally runs. If try throws an error, finally runs.

Even if try has a return statement, finally runs before the function actually returns.

javascript

function readAndProcess(path) {
  const handle = openFile(path);
  try {
    return parseData(handle);
  } finally {
    closeFile(handle);
  }
}

This is the core use of finally: resource cleanup that must happen no matter what. The file handle closes whether parseData succeeds, fails, or the function returns early.

When finally runs

finally executes after the try block, and the catch block if one is present, but before control returns to the caller.

javascript

function showWhenFinallyRuns() {
  try {
    console.log("1. Inside try");
    return "result from try";
  } finally {
    console.log("2. Inside finally");
  }
}
 
console.log(showWhenFinallyRuns());
// 1. Inside try
// 2. Inside finally
// result from try

The return in try computes its value immediately, but the function does not exit until finally completes. With an error present, catch runs before finally, in the same order it would without a return:

javascript

function showFinallyWithError() {
  try {
    throw new Error("oops");
  } catch (e) {
    console.log("Inside catch:", e.message);
  } finally {
    console.log("Inside finally");
  }
}
 
showFinallyWithError();
// Inside catch: oops
// Inside finally

The finally block always executes. The only question the diagram highlights is whether it changes the outcome by using its own return or throw.

The return override trap

A return, throw, break, or continue inside finally overrides whatever the try or catch block intended to do:

javascript

function dangerous() {
  try {
    return "from try";
  } finally {
    return "from finally";
  }
}
 
console.log(dangerous());

This logs "from finally", not "from try", because the finally block's own return statement wins. The same thing happens with throw, and it is even more dangerous there, since it silently discards the original error:

javascript

function dangerousThrow() {
  try {
    throw new Error("original error");
  } finally {
    throw new Error("finally error");
  }
}
 
try {
  dangerousThrow();
} catch (e) {
  console.log(e.message); // "finally error", the original is lost forever
}

The rule is simple: never put return, throw, break, or continue inside finally. The block should only contain cleanup code, such as closing connections, clearing state, or removing listeners. If you need conditional logic based on success or failure, put it in catch or after the block instead.

try...finally without catch

You do not need a catch block. try...finally is a valid form on its own:

javascript

function withCleanup(fn) {
  const start = performance.now();
  try {
    return fn();
  } finally {
    console.log(`Took ${performance.now() - start}ms`);
  }
}

If fn throws, the timing still logs, and then the error propagates up to the caller unchanged. This pattern is perfect when you want to observe or clean up but let the caller handle the actual error. A practical use is temporarily changing a global setting and restoring it afterward:

javascript

function runInDebugMode(fn) {
  const previous = appConfig.debug;
  appConfig.debug = true;
  try {
    return fn();
  } finally {
    appConfig.debug = previous;
  }
}

Without finally, a thrown error inside fn would leave debug permanently set to true, since the line that restores it would never run.

Real-world cleanup patterns

Closing a database connection is one of the most common uses of finally, since the pool needs the client back whether the query succeeded or not:

javascript

async function queryDatabase(sql) {
  const client = await pool.connect();
  try {
    return await client.query(sql);
  } finally {
    client.release();
  }
}

Clearing a loading state follows the same shape as the database example above, so the spinner cannot get stuck visible on screen after a failed request:

javascript

async function loadDashboard() {
  showSpinner();
  try {
    const data = await fetchDashboardData();
    render(data);
  } catch (error) {
    showErrorBanner("Failed to load dashboard");
  } finally {
    hideSpinner();
  }
}

If hideSpinner were placed after the try...catch instead of inside finally, an unhandled error in catch would leave the spinner visible forever, since nothing after a rethrow would ever run.

finally vs code after try...catch

javascript

try {
  const file = openFile();
  process(file);
} finally {
  closeFile(file); // Must run either way
}

Code placed after the whole try...catch block, by contrast, only executes when nothing throws, which is exactly why sendSuccessNotification below waits until after closeFile instead of living in finally:

javascript

try {
  const file = openFile();
  process(file);
  closeFile(file);
  sendSuccessNotification(); // Only reached if no error
} catch (e) {
  console.error(e);
}

Common mistakes

Accidentally overriding a return value is the most common mistake. If the try block returns a value but finally also returns something, or changes the value being returned, the actual result can surprise you. Avoid return in finally completely.

Putting non-cleanup logic in finally is a quieter mistake. If the code is not about releasing resources or restoring state, it probably belongs outside the block:

javascript

try {
  doWork();
} finally {
  trackEvent("work_completed"); // This is business logic, not cleanup
}

Analytics tracking depends on whether the work actually succeeded, so it reads more clearly split across catch and the success path instead of living unconditionally in finally:

javascript

try {
  doWork();
  trackEvent("work_completed");
} catch (e) {
  trackEvent("work_failed");
}

Assuming finally catches everything is the last mistake. If the try block calls process.exit in Node.js, or the browser tab closes, finally will not run. It guards against JavaScript exceptions and return statements, not process termination.

For the full try...catch syntax including conditional catch and nesting, see the try...catch guide. For more on the throw statement, see throwing errors in JavaScript.