Error Handling with Result Types

The plain-language idea

throw in TypeScript has a well-known hole: nothing in a function's type signature says it can throw, or what it throws. catch (e) gives you e: unknown — deliberately, because the language has no way to guarantee what actually gets thrown. The compiler can't force a caller to handle an error it doesn't know exists.

A Result type moves failure into the return type instead. Result<T, E> is a discriminated union — the same tool from the discriminated unions lesson — that's either a success carrying a T or a failure carrying an E. A function that returns Result<User, ParseError> is telling every caller, right there in the signature, that it can fail and exactly what the failure looks like. There's no way to reach the T without going through a check the compiler can verify you performed.

See it in a real thing: parsing user input without throwing

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

function ok<T>(value: T): Result<T, never> {
  return { ok: true, value };
}
function err<E>(error: E): Result<never, E> {
  return { ok: false, error };
}

type ParseError = { reason: "empty" | "not-a-number" };

function parseAge(input: string): Result<number, ParseError> {
  if (input.trim() === "") return err({ reason: "empty" });
  const n = Number(input);
  if (Number.isNaN(n)) return err({ reason: "not-a-number" });
  return ok(n);
}

const result = parseAge("42");

if (result.ok) {
  console.log(result.value + 1); // value: number — only reachable after the check
} else {
  console.log(result.error.reason); // error: ParseError — only reachable in this branch
}

Try accessing result.value before checking result.ok and TypeScript rejects it — value only exists on the { ok: true } branch of the union, and the compiler has no way to know which branch you have until you narrow it. That if (result.ok) check is doing the same job try/catch does, except the compiler can actually see whether you wrote it.

What people usually miss

Watch out

• throw is invisible to the type checker; Result isn't. A function typed (input: string) => number might throw, might not — nothing in the signature says so, and TypeScript will never warn a caller who forgot a try. A function returning Result<number, ParseError> makes the failure path part of the contract.
• This isn't "never throw again." Programmer errors — a genuinely impossible state, an assertion that should never fail — are still reasonable to throw. Result types are for expected, recoverable failures: bad input, a network call that might 404, a lookup that might miss. Reserve throw for bugs, Result for outcomes.
• Forgetting to check .ok doesn't silently succeed. Accessing .value without narrowing is a compile error, not a runtime undefined — that's the entire value proposition over a plain { data, error } object where both fields exist unchecked and nothing stops you reading the wrong one.

Why this matters in interviews

"What's the actual difference between throwing and returning a Result type?" is a real design question, not trivia — a strong answer explains that throw bypasses the type system entirely while Result puts the failure path through the same exhaustiveness checking as any other discriminated union, and can name a case where each approach is the right call.