Result Types

1enum PaymentError {
2    Declined { code: String },
3    Unavailable { waited_ms: u64 },
4}
5 
6fn charge(order: &Order) -> Result<Payment, PaymentError> { /* ... */ }
7 
8fn checkout(order: &Order) -> Result<Receipt, PaymentError> {
9    let payment = charge(order)?;          // propagates, no restating
10    Ok(Receipt::for_payment(payment))
11}
12 
13fn present(order: &Order) -> String {
14    match charge(order) {
15        Ok(p) => format!("charged {}", p.id),
16        Err(PaymentError::Declined { code }) => format!("declined: {code}"),
17        Err(PaymentError::Unavailable { .. }) => "try again shortly".into(),
18        // adding a third variant makes THIS a compile error
19    }
20}

A panic from a bug is not a PaymentError and cannot be matched here. That separation is enforced by the type, not by convention — which is exactly the property a TypeScript version has to buy with a lint rule and a code review habit.

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

function present(r: Result<Payment, PaymentError>) {
  if (r.ok) return `charged ${r.value.id}`
  if (r.error.kind === 'declined') return 'declined'
  // 'unavailable' silently falls through to undefined,
  // and so will every case added later
}

charge(order)   // floating promise, result discarded, no warning

function present(r: Result<Payment, PaymentError>): string {
  if (r.ok) return `charged ${r.value.id}`
  switch (r.error.kind) {
    case 'declined':    return `declined: ${r.error.code}`
    case 'unavailable': return 'try again shortly'
    default:            return assertNever(r.error)  // compile error on a 3rd case
  }
}

const assertNever = (x: never): never => { throw new Error(`unhandled ${JSON.stringify(x)}`) }
// plus: no-floating-promises + a no-unused-result lint in CI

The type is identical; only the enforcement differs, and the enforcement is the entire value proposition. A team that adopts the shape without the lint rules has taken on the ceremony and kept the original bug, which is the most common way this design fails in practice.

caveat These scores assume a language where exhaustiveness and non-discarding can be enforced at all. In Python or Java without checked exceptions the testability advantage of Result shrinks to a convention, and the simplicity penalty stays exactly the same — which flips the recommendation for a lot of real codebases. The scores also say nothing about the team: five engineers who have never used sum types will write worse Result code than good exception code, and that is a legitimate input to the decision.