MEDIUMQualitysmallError Handling

Use Result-style returns for expected failures

Model predictable outcomes (validation, not-found, parse failures) as typed return values; reserve throwing for truly exceptional conditions. This makes failure paths explicit and type-checked.

Why This Matters

Throwing for routine, expected outcomes hides control flow from the type system, so callers forget to handle common failures.

Related Rules

Use Error Boundaries

Quality

HIGH

Log Errors with Context

Quality

HIGH

Never silently swallow errors

Quality

HIGH

Fail fast and handle errors at boundaries

Quality

HIGH

Catch this automatically on every PR

BeforeMerge scans your pull requests against this rule and dozens more. Get actionable feedback before code ships.

Join Waitlist Browse All Rules

Why this matters

When a failure is an ordinary, expected outcome, encoding it in the return type forces callers to handle it and keeps stack-unwinding cost out of the hot path. Reserve throw for exceptional, unrecoverable conditions.

// Bad — caller can't see that "invalid" is a normal case
function parseAge(s: string): number {
  const n = Number(s);
  if (Number.isNaN(n)) throw new Error("bad age");
  return n;
}
 
// Good — explicit, type-checked outcome
type Result<T> = { ok: true; value: T } | { ok: false; error: string };
function parseAge(s: string): Result<number> {
  const n = Number(s);
  return Number.isNaN(n) ? { ok: false, error: "bad age" } : { ok: true, value: n };
}