try/catch, finally, and Rethrow in Async Functions

## The problem `await` solves Before async/await, asynchronous failures were structurally uncatchable by `try`/`catch`. A callback or a `.then` continuation runs on a later turn of the event loop, on a fresh call stack. By then the `try` block that started the work has already exited, so there is no live handler frame for an exception to unwind into. Wrapping `fetchUser().then(handle)` in a `try` catches only errors thrown while *starting* the work, never the failure the work reports later. ## What `await` actually does `await expr` suspends the async function until `expr` settles, then resumes it in one of exactly two ways: - The promise **fulfils** → the `await` expression evaluates to the fulfilment value and execution continues on the next line. - The promise **rejects** → the `await` expression **throws** the rejection reason at that point, as if `throw reason` appeared on that line. That second rule is the whole mechanism. Rejection is converted back into an ordinary exception at a specific, visible point in the source, so the language's ordinary exception machinery applies again. ```js async function load(id) { try { const user = await fetchUser(id); // rejection throws here return user.name; } catch (err) { console.error('load failed', err); return null; } } ``` The function returns a promise either way: it fulfils with `user.name` on the happy path, and fulfils with `null` on the failure path, because the `catch` handled the error and returned a value. Handling an error inside an async function turns a rejection into a fulfilment unless you rethrow. ## The catch binding holds a reason, not necessarily an Error `throw` accepts any value in JavaScript, and so does `Promise.reject`. The catch parameter is bound to whatever the promise rejected with. A handler that immediately reads `err.message` silently produces `undefined` for a string rejection and throws a `TypeError` for a `null` one. Robust handlers narrow first: ```js catch (err) { const message = err instanceof Error ? err.message : String(err); logger.warn(message); } ``` This matters more with async code than with synchronous code, because rejection reasons often cross a library boundary you do not control. ## Only the awaits inside the block are protected A `try` block guards the awaits that are lexically inside it, and nothing else. If a promise is created inside the `try` but awaited after it, the rejection surfaces at the later `await`, outside the handler. If a promise is created and never awaited, nothing ever throws into that block at all, because the call that produced it returned normally. The practical rule is that the `try` should bracket the `await`, not merely the call that starts the work. ## A synchronous throw inside the callee still arrives as a rejection An async function never throws synchronously to its caller. If `fetchUser` validates its argument and throws on its very first line, before any `await`, the thrown value does not propagate up the caller's stack — it is captured and used to reject the promise the call returned. From the caller's side, an argument-validation bug and a network failure surface identically, at the `await`: ```js async function fetchUser(id) { if (!id) throw new TypeError('id required'); // becomes a rejection return api.get(`/users/${id}`); } ``` That uniformity is deliberate: callers of an async function need exactly one error channel, the returned promise, rather than two. ## Where the catch clause actually runs When an async function suspends at `await`, its remaining body is registered as a continuation on the awaited promise and resumed as a promise job. So the `catch` clause executes on a later turn, on a call stack that no longer contains the caller that invoked the async function. Two consequences are worth naming in an interview. First, the resumed code still sees the same variables — resumption restores the function's environment, so closures and locals are intact. Second, the caught error's stack trace was captured where the error was *created*, which may be deep inside a library; the frames that were live where you wrote the `await` are only visible if the engine records async stack traces, which V8 does for awaited frames but not for every promise shape. ## try/catch versus a `.catch` handler Both catch the same failures. `try`/`catch` protects a region of code and reads sequentially, which is why it dominates in async functions; `.catch` attaches to a single promise and is the only option outside an async function. What you should not conclude is that `try`/`catch` gained new powers — it did not. `await` did the work by moving the failure back onto the throwing path.