Lesson 29 of 80

Error Handling & Custom Errors

Q: How would you design error handling for an API layer, including custom error types?

A strong answer covers: Custom errors extend Error (via class ... extends Error) to get correct .stack and instanceof behavior, plus custom fields; await bridges promise rejections into regular try/catch; a plain .then() chain still needs its own .catch(); Distinguish expected/recoverable errors (validation, 404) worth a specific type and handling from unexpected ones that should propagate rather than be silently swallowed.

try/catch, promise rejection, and async/await error handling are three faces of the same mechanism — and custom Error subclasses are how you make failures carry useful, specific information.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Inside an async function, can a regular `try/catch` catch a rejected promise from `await fetch(...)`?

Yes — await turns a rejection into a thrown exception that try/catch handles normallyNo — rejected promises can only be caught with .catch()Only if the fetch call itself is wrapped in Promise.resolve() first

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Error Handling & Custom Errors

What interviewers actually ask about this, and what a strong answer has to cover.

How would you design error handling for an API layer, including custom error types?

A strong answer covers

Custom errors extend Error (via class ... extends Error) to get correct .stack and instanceof behavior, plus custom fields
await bridges promise rejections into regular try/catch; a plain .then() chain still needs its own .catch()
Distinguish expected/recoverable errors (validation, 404) worth a specific type and handling from unexpected ones that should propagate rather than be silently swallowed

Likely follow-ups

What does finally guarantee that try/catch alone doesn't?
How would you make instanceof checks reliable for custom errors across module boundaries?
What's the risk of a bare catch (err) { } that does nothing with err?

Practice these with the AI interviewer →

The plain-language idea

class ValidationError extends Error {
  constructor(message, field) {
    super(message);           // sets this.message, wires up the stack trace
    this.name = "ValidationError";
    this.field = field;       // custom data specific to this error type
  }
}

function validate(input) {
  if (!input.email) throw new ValidationError("email is required", "email");
}

try {
  validate({});
} catch (err) {
  if (err instanceof ValidationError) {
    console.log(`${err.field}: ${err.message}`);
  } else {
    throw err;                // don't swallow errors you don't know how to handle
  }
}

extends Error gets you .message, .stack, and correct instanceof behavior — you're using the prototype-chain-based inheritance from the prototypes lesson, applied to error types.

try/catch covers async/await too

async function loadUser(id) {
  try {
    const res = await fetch(`/users/${id}`);
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  } catch (err) {
    console.error("Failed to load user:", err.message);
    throw err;
  }
}

An awaited promise's rejection becomes a regular throw inside the async function — the same try/catch you'd use for synchronous code catches it. This only works with await; a plain (non-awaited) .then() chain needs its own .catch().

await + try/catch: one mechanism for sync and asyncStep 1 of 4

await fetch(...) rejects. Inside a try block, that rejection becomes a normal thrown exception.

What people usually miss

Watch out

Re-throw errors you don't recognize. Catching everything and silently swallowing it hides real bugs — catch specifically what you can handle, and re-throw the rest.
A finally block always runs, whether the try succeeded, threw, or even returned early — it's the right place for cleanup (closing a connection, hiding a loading spinner) that must happen either way.
Promise.reject(new Error(...)) and throw inside an async function are equivalent — both produce a rejected promise, which is why try/catch around await correctly catches both.

Why this matters in interviews

"Design an error-handling strategy for an API layer" tests whether you distinguish expected failures (validation, 404) that deserve custom error types from truly unexpected ones that should propagate loudly rather than being swallowed.