Error Handling

Errors are inevitable — networks fail, inputs are invalid, code has bugs. A consistent error-handling strategy makes your program predictable: crashes are rare and contained, failure modes are documented, and debugging is faster.

try / catch / finally

try {
  // Code that might throw
  const data = JSON.parse(rawInput); // throws SyntaxError on bad JSON
  process(data);
} catch (err) {
  // Runs only if something in `try` throws
  // `err` is typed `unknown` in TypeScript — always narrow it
  if (err instanceof SyntaxError) {
    console.error("Invalid JSON:", err.message);
  } else {
    throw err; // re-throw what we cannot handle
  }
} finally {
  // Always runs — use for cleanup (close connections, release locks)
  cleanup();
}

Built-in Error Types

JavaScript has several built-in Error subtypes, each thrown by the engine in specific situations:

Custom Error Classes

Extend Error to add domain-specific context:

class ApiError extends Error {
  constructor(
    message: string,
    public readonly status: number,
    public readonly code: string
  ) {
    super(message);
    this.name = "ApiError"; // set name explicitly for stack traces
    // Fix prototype chain in some older transpiler targets
    Object.setPrototypeOf(this, new.target.prototype);
  }
}

class NotFoundError extends ApiError {
  constructor(resource: string) {
    super(`${resource} not found`, 404, "NOT_FOUND");
    this.name = "NotFoundError";
    Object.setPrototypeOf(this, new.target.prototype);
  }
}

// Usage
function getUser(id: number) {
  if (!db.has(id)) throw new NotFoundError(`User #${id}`);
  return db.get(id);
}

try {
  getUser(99);
} catch (err) {
  if (err instanceof NotFoundError) {
    // Handle 404
  } else if (err instanceof ApiError) {
    // Handle other API errors
  } else {
    throw err; // unexpected — re-throw
  }
}

Error Handling in Async Code

async/await

async function fetchData(url: string): Promise<unknown> {
  let response: Response;
  try {
    response = await fetch(url);
  } catch (err) {
    // Network failure — fetch itself threw (DNS error, connection refused)
    throw new Error(`Network error: ${String(err)}`);
  }

  if (!response.ok) {
    // HTTP error status (4xx, 5xx) — fetch does NOT throw for these
    throw new ApiError(response.statusText, response.status, "HTTP_ERROR");
  }

  return response.json();
}

Promise chains

fetchData("/api/users")
  .then(handleData)
  .catch((err) => {
    if (err instanceof ApiError && err.status === 401) {
      redirectToLogin();
    } else {
      showErrorToast(err.message);
    }
  });

Throw vs Return an Error Value

Throw when the error is exceptional and the caller should not silently ignore it:

• Invalid arguments that indicate a programming mistake
• Unexpected network / system failures

Return an error value (result pattern) when failure is a normal, expected outcome:

type Result<T, E = Error> =
  | { ok: true; value: T }
  | { ok: false; error: E };

function parseAge(input: string): Result<number> {
  const n = Number(input);
  if (Number.isNaN(n) || n < 0 || n > 150) {
    return { ok: false, error: new RangeError(`Invalid age: ${input}`) };
  }
  return { ok: true, value: n };
}

const result = parseAge("abc");
if (!result.ok) {
  console.error(result.error.message);
}

Further Learning

Search these terms to go deeper:

• “MDN: Error” — reference for all built-in error types and properties
• “TypeScript error handling patterns” — articles on narrowing unknown errors and the result pattern
• “neverthrow library” — TypeScript library implementing the Result/Either pattern
• “fetch error handling JavaScript” — specifically covers the confusing response.ok vs promise rejection distinction
• “JavaScript global error handling” — window.onerror, unhandledrejection events for last-resort error capture

Error Handling

Things go wrong: the internet drops, a user types nonsense, code has bugs. Good error handling means your app bends instead of breaking — it catches the problem, does something sensible, and keeps going.

try / catch / finally

Wrap risky code in try. If it fails, catch runs instead of crashing. finally runs no matter what:

try {
  const data = JSON.parse(rawInput)  // might fail on bad input
  process(data)
} catch (err) {
  console.error('Something went wrong:', err)
} finally {
  cleanup()  // always runs — good for closing things
}

Think of it as: “try this; if it breaks, catch it here; and finally, always do this cleanup.”

Throwing your own errors

You can raise an error on purpose with throw when something isn’t valid:

function getUser(id) {
  if (!id) {
    throw new Error('User id is required')
  }
  // ...
}

The nearest catch up the call chain will receive it.

The common built-in errors

JavaScript throws a few types automatically. You’ll recognize these from real bugs:

Errors in async code

With async/await, error handling looks exactly the same — just try/catch:

async function loadData() {
  try {
    const res = await fetch('/api/data')
    if (!res.ok) throw new Error(`Server said ${res.status}`)
    return await res.json()
  } catch (err) {
    console.error('Load failed:', err)
  }
}

When to throw vs. handle gently

• Throw when something is truly broken or unexpected (a real bug, a missing required value).
• Handle and continue when failure is normal and expected (a search returned nothing, an optional field is missing) — don’t crash the app over routine cases.

In one sentence

Wrap risky code in try/catch (with finally for cleanup), throw your own errors when inputs are invalid, and remember async errors are caught the same way — just check res.ok after a fetch.

Want to go deeper?

Switch to Expert mode above for custom Error subclasses, the full built-in error list, and the Result pattern for expected failures.