Week 8: async/await & Error Handling

1. async/await Syntax

An async function always returns a Promise, and inside it, the await keyword pauses execution until a Promise settles — without blocking the rest of the program, exactly like a .then() callback would:

function loadUser(id) {
  return fetchUser(id)
    .then((user) => fetchOrders(user.id))
    .then((orders) => console.log(orders))
    .catch((err) => console.log("Failed:", err.message));
}

async function loadUser(id) {
  try {
    const user = await fetchUser(id);   // pauses here until fetchUser resolves
    const orders = await fetchOrders(user.id);
    console.log(orders);
  } catch (err) {
    console.log("Failed:", err.message);
  }
}

Both versions do exactly the same thing — await is quietly still using .then() underneath, and try/catch is quietly still catching a rejection, the same way .catch() does. What's genuinely different is readability: the async/await version reads top to bottom, in the same shape as ordinary synchronous code, instead of a chain of callbacks.

2. Error Handling With try/catch

A rejected awaited Promise throws — exactly like a synchronous error — which is why try/catch, not .catch(), is the standard way to handle failures in async/await code:

async function loadUser(id) {
  try {
    const user = await fetchUser(id); // throws if fetchUser's Promise rejects
    return user;
  } catch (err) {
    console.log("Could not load user:", err.message);
    return null; // a sensible fallback, instead of letting the error crash the caller
  }
}

Anything thrown or rejected anywhere inside the try block — across any number of await lines — is caught by the single catch block, the same way one .catch() covers an entire Promise chain. If a function doesn't wrap its await calls in try/catch at all, an unhandled rejection propagates up to whatever called it — which is itself a valid choice sometimes, but should be deliberate, not accidental.

3. Awaiting Multiple Promises

awaiting one Promise after another looks reasonable, but silently costs time when the operations don't actually depend on each other:

async function loadDashboard() {
  const user = await fetchUser(1);       // waits ~300ms
  const products = await fetchProducts(); // THEN waits another ~300ms
  return { user, products };              // total: ~600ms
}

async function loadDashboard() {
  const [user, products] = await Promise.all([
    fetchUser(1),      // both start immediately, at the same time
    fetchProducts(),
  ]);
  return { user, products }; // total: ~300ms -- roughly the slower of the two, not the sum
}

fetchProducts() in the first version doesn't even start until fetchUser(1) has fully finished, purely because of the order the await keywords appear on the page — even though the two calls have nothing to do with each other. Promise.all starts every Promise in the array immediately and waits for all of them together, so independent operations run concurrently instead of piling their durations on top of each other. Reach for sequential await only when one step genuinely needs the previous step's result — like loadUser's fetchOrders(user.id) earlier, which needs user.id from the first call.

4. Common Async Mistakes

A few habits worth building deliberately, since the alternative fails quietly rather than with an obvious error:

async function loadUser(id) {
  const user = fetchUser(id); // missing await!
  console.log(user.name);     // TypeError: user is a Promise, not the resolved value
}

async function loadAll(ids) {
  // .map()'s callback returns a Promise each time, but .map() itself has no
  // idea it's async -- it doesn't wait, so `results` is an array of PROMISES.
  const results = ids.map(async (id) => await fetchUser(id));
  console.log(results); // [Promise, Promise, Promise] -- not the actual users

  // Fix: wrap the whole array of Promises in Promise.all
  const users = await Promise.all(ids.map((id) => fetchUser(id)));
  console.log(users); // the actual resolved user objects
}

Forgetting await leaves you holding a Promise object instead of its resolved value — usually surfacing as a confusing error on whatever line tries to use it. The .map() mistake is subtler: .map() has no special awareness of async callbacks, so it happily builds an array of still-pending Promises and moves on immediately; Promise.all around the whole thing is what actually waits for every one of them to resolve.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.