Introduction

Errors thrown inside a setTimeout callback are asynchronous. That means a try or catch wrapped around the setTimeout(...) call itself will not catch exceptions that happen later inside the callback.

The rule of thumb is simple: catch the error where the delayed work actually runs, or convert the delayed work into a Promise-based flow and handle rejection there.

Why Outer try and catch Does Not Work

This does not do what many people expect:

1try {
2  setTimeout(() => {
3    throw new Error("boom");
4  }, 0);
5} catch (err) {
6  console.log("caught", err.message);
7}

The catch block will not run. By the time the callback executes, the surrounding stack frame has already finished.

That is the key mental model: setTimeout schedules work, it does not execute that work synchronously.

Catch Errors Inside the Callback

If the code inside the timeout can throw, handle it there.

1setTimeout(() => {
2  try {
3    riskyOperation();
4  } catch (err) {
5    console.error("timeout callback failed", err);
6  }
7}, 1000);
8
9function riskyOperation() {
10  throw new Error("bad data");
11}

This is the simplest and most direct fix.

If the callback is long, move the work into a named function.

1function runLater() {
2  try {
3    riskyOperation();
4  } catch (err) {
5    console.error("runLater failed", err);
6  }
7}
8
9setTimeout(runLater, 1000);

Promise Wrapper for Structured Async Code

If you are already using async and await, wrap the delay in a Promise so errors follow the normal async control flow.

1function delay(ms) {
2  return new Promise((resolve) => setTimeout(resolve, ms));
3}
4
5async function main() {
6  try {
7    await delay(1000);
8    riskyOperation();
9  } catch (err) {
10    console.error("async flow failed", err);
11  }
12}
13
14main();

This does not make setTimeout itself throw differently. It just puts the delayed work into a structure that is easier to compose and test.

Dealing with Async Functions Inside setTimeout

There is another subtle case: the callback itself may be async.

1setTimeout(async () => {
2  try {
3    await doAsyncWork();
4  } catch (err) {
5    console.error("async timeout error", err);
6  }
7}, 500);

If you omit the inner try and catch, a rejected Promise may become an unhandled rejection depending on the runtime and configuration.

So the same principle still applies: handle the failure inside the callback or inside the async function it calls.

Global Handlers Are a Last Resort

Browsers and Node.js both expose global hooks for unhandled problems.

Browser example:

window.addEventListener("error", (event) => {
  console.error("global error", event.error);
});

Node.js example:

process.on("uncaughtException", (err) => {
  console.error("uncaught exception", err);
});

These are useful for logging and crash visibility, but they are not a substitute for local error handling. Treat them as safety nets, not primary control flow.

Cancellation Is Different from Error Handling

Sometimes the right answer is not to catch the error but to avoid running the timeout at all.

1const timer = setTimeout(() => {
2  console.log("will not run");
3}, 2000);
4
5clearTimeout(timer);

clearTimeout prevents future execution if the callback has not started yet. It does not catch errors from a callback that is already running.

Common Pitfalls

The biggest mistake is wrapping setTimeout(...) in try and catch and assuming that catches callback failures. It does not.

Another common issue is forgetting that async callbacks can reject just as easily as synchronous callbacks can throw.

People also rely too heavily on global error handlers. Those are valuable for observability, but local handling is still the correct place to decide what recovery should happen.

Finally, delayed errors can be harder to trace because the original scheduling call happened earlier. Good logging inside the callback helps a lot.

Summary

• Errors thrown inside a setTimeout callback are asynchronous.
• An outer try and catch around setTimeout(...) will not catch them.
• Catch exceptions inside the callback or inside the function it calls.
• Promise wrappers make delayed work easier to integrate with async and await.
• Use global error handlers only as a safety net.
• 'clearTimeout cancels scheduled work, but it is not an error-handling mechanism.'