async and await

`async` and `await` are not a third asynchronous system sitting beside callbacks and promises. They are a way of writing promise code that reads like ordinary top-to-bottom code. Underneath, the promises and the microtask queue from the last two lessons are doing exactly what they did before.

That is good news twice over. Everything you learned about states, settling once and chaining still applies. And when something goes wrong, the debugging question is still "which promise is this, and what settled it?"

There are only two pieces to learn: what `async` does to a function, and what `await` does inside one.

Put `async` in front of a function and one thing changes: the value you return is no longer what the caller gets. MDN is blunt about it — async functions always return a promise, and a returned value that is not already a promise is wrapped in one.

So `async function greet() { return "hi"; }` called as `greet()` hands back a promise that fulfils with "hi". The string is in there; it is not what you are holding.

Throwing follows the same route. An exception that escapes the body does not reach the caller as an exception — it becomes a rejection of the returned promise. This is the trade that makes the rest work: because both outcomes travel inside one promise, the caller has one thing to wait on and one place to look for failure.

`await somePromise` waits for the promise and gives you its fulfilment value — as a plain value, on that line, in a variable. That is the whole appeal: the pyramid of handlers becomes a straight line.

But read the word "waits" carefully. Nothing about `await` blocks the thread. What MDN describes is that the awaited expression is evaluated, the code depending on it is paused, control leaves the function and returns to the caller, and when the value resolves a microtask is scheduled to continue the paused code.

So the caller carries on immediately. The rest of your async function is a continuation, queued like any other job. `await` is a promise handler wearing more comfortable clothes.

One detail worth knowing before it confuses you: the body up to and including the first `await` runs synchronously, so an async function with no `await` in it runs entirely synchronously — it just hands back a promise at the end. And awaiting a non-promise still pauses: MDN notes the value is converted to a resolved promise and execution still waits until the next tick.

Here is the model to keep. Take an async function and draw a line at each `await`. Everything above the first line runs when you call it, synchronously, like any function. Every piece below a line is a separate job, queued when the awaited promise settles.

Now the surprising behaviours stop being surprising. Code after the call runs before the code after the first `await`, because the caller resumed while your function was parked. A `console.log` at the top of an async function prints immediately, while one after an `await` does not. And a variable you set after an `await` is not set yet for anybody who reads it in between.

Use this model to answer ordering questions the same mechanical way as the last lesson: where are the cut lines, and which piece is queued when?

When an awaited promise rejects, the `await` expression throws the rejection reason. That is the second big win after flat code: `try` / `catch` / `finally`, which you already learned for synchronous code, works unchanged.

So the three shapes converge. An error-first callback checks a parameter, a promise chain uses `.catch`, and an async function uses `try`/`catch` — and the last of those is the one you would have written before you knew anything about asynchronous code at all.

Two things do not change. An unhandled rejection is still unhandled: if nothing catches it, it propagates out and rejects the promise your async function returned, and if nobody handles that either the runtime reports it. And `finally` still means "either way" — the natural place for cleanup.

Forgetting `await`. `const user = loadUser();` gives you a promise; `user.name` is `undefined` and nothing warns you. The whole final lesson of this module is about spotting this symptom.

Awaiting outside an async function. `await` is allowed inside an async function or at the top level of a module. In an ordinary function it is a syntax error, and in this sandbox — which evaluates programs as a script, not a module — top-level `await` is a syntax error too. Wrap the work in an async function and call it.

Assuming `await` blocks everything. It suspends only the function it appears in. Timers keep firing, event handlers keep running, and the caller has already continued.

`return promise` inside a `try`. A plain `return somePromise;` hands the promise back before this function's `catch` can see it fail, so a rejection escapes to the caller instead. `return await somePromise;` waits here, turning the rejection into an exception this `try` block can actually catch.

Sprinkling `async` everywhere. `async` on a function with no `await` in it adds a promise wrapper and nothing else, forcing every caller to await something that was never asynchronous. Add it when you need `await` inside.

The gain is not that there is less to type. It is that asynchronous code goes back to using the tools you already have: variables hold values, `try`/`catch` handles failure, `if` and `for` work normally, and the order of the lines matches the order of the steps.

That said, `.then` has not gone anywhere and you will read plenty of it. The two mix freely, because an async function returns a promise and `await` accepts one. The rule of thumb is one style per function: mixing `await` and `.then` inside a single function is where error handling gets genuinely confusing, and that is the last mistake in the next lesson.

`async` makes a function return a promise — fulfilled with what you return, rejected with what you throw. `await` unwraps a promise into a value, pausing only that function while the caller carries on; the rest of the body becomes a queued continuation. Rejections become exceptions, so `try`/`catch`/`finally` works. `await` needs an async function (or a module's top level), and inside a `try` you often want `return await`.