Error handling and program robustness across paradigms

Every non-trivial program meets situations it cannot handle normally: a file is missing, input is malformed, a network request times out, a value is out of range. How a language represents and propagates these failures is a paradigm choice with large consequences for robustness. This lesson compares four approaches: special return values and error codes, as in C; exceptions, as in Python and Java; result and option types, as in Rust and functional languages; and defensive techniques that cut across paradigms, such as validation at boundaries, assertions and contracts. The goal is to choose an approach that makes failures hard to ignore and easy to handle in the right place.

Kinds of failure

It helps to separate three kinds of failure before choosing a mechanism. Expected failures are part of normal operation: a user types a bad date, a lookup finds nothing, a file that may or may not exist is absent. Environmental failures come from outside the program and can happen at any time: the disk is full, the network drops, memory runs out. Bugs are mistakes in the program itself: an index out of range, a violated invariant, a null where an object was required. Expected failures should be handled close to where they occur. Environmental failures often must travel up to a level that can retry, report or give up. Bugs should be detected early and loudly, not quietly handled, because handling a bug usually hides it.

Error codes and special values

The oldest approach returns a special value to signal failure. C functions return −1 or `NULL` and set the global `errno`, as you saw in CMPUT-201. Python's `str.find` returns −1 when the substring is absent, and `dict.get` returns `None`. The approach is simple and cheap, but it has two serious weaknesses. Nothing forces the caller to check, so errors are easy to ignore. And the special value can collide with a legitimate result: if a function computes a number that can be negative, −1 cannot mean failure.

text = "paradigms"
i = text.find("z")              # -1 means not found
print("index:", i, "| text[i] =", repr(text[i]))   # bug: -1 silently indexes the LAST char

prices = {"tea": 350}
p = prices.get("coffee")        # None means absent
try:
    print(p * 2)
except TypeError as err:
    print("later failure:", err)

index: -1 | text[i] = 's'
later failure: unsupported operand type(s) for *: 'NoneType' and 'int'

The first line shows how quietly a special value can go wrong: −1 is a valid Python index meaning the last character, so the unchecked result produces a plausible but wrong answer instead of an error. The second failure happens at the multiplication, not at the lookup that caused it, which makes the bug harder to trace. Both problems come from the same source: the failure is encoded in an ordinary value that the type system and the reader can easily treat as a success.

Exceptions

Exceptions separate the error path from the normal path. When a function cannot do its job, it raises an exception, and control jumps up the call stack to the nearest handler for that kind of exception, skipping the intermediate code. If no handler exists, the program stops with a traceback. Exceptions cannot be ignored silently: an unhandled exception is visible. They also keep the main logic uncluttered, because intermediate functions need no error-checking code to pass failures upward.

class ConfigError(Exception):
    """Raised when the configuration cannot be loaded."""

def read_file(path):
    files = {"app.cfg": "port=8080\nhost=example.org"}
    if path not in files:
        raise FileNotFoundError(path)
    return files[path]

def parse(text):
    try:
        return {k: v for k, v in (line.split("=", 1) for line in text.splitlines())}
    except ValueError as err:
        raise ConfigError("malformed line") from err       # keep the cause

def load_config(path):          # no error handling needed here
    return parse(read_file(path))

for path in ["app.cfg", "missing.cfg"]:
    try:
        cfg = load_config(path)
        print("loaded:", cfg)
    except FileNotFoundError as err:
        print("using defaults; not found:", err)
    finally:
        print("  (attempted", path + ")")

loaded: {'port': '8080', 'host': 'example.org'}
  (attempted app.cfg)
using defaults; not found: missing.cfg
  (attempted missing.cfg)

Good exception handling follows a few rules. Catch specific exception types, not everything: a bare `except:` also catches keyboard interrupts and programming errors that should crash. Catch at the level that can do something useful, such as retry, substitute a default or report to the user; elsewhere, let exceptions pass. Use `raise ... from err` to wrap a low-level exception in a domain-specific one while keeping the original as the cause. And release resources with `finally` or, better, a `with` statement, which guarantees clean-up even when an exception passes through.

Exceptions have costs. They are invisible in function signatures in Python, so you must read documentation or code to know what a call can raise. Java tried to fix this with checked exceptions, which must be declared in a method's `throws` clause and handled by callers, but many programmers found them verbose and wrapped them in unchecked exceptions, and later languages such as C# and Kotlin did not adopt them. Exceptions also make control flow non-local, which can surprise readers and complicates reasoning about state: if an exception occurs halfway through updating several fields, the object may be left inconsistent unless the update is designed to be all or nothing.

Result and option types

Functional languages usually represent failure in the return type. An option type, called `Option` in Rust, `Maybe` in Haskell and `Optional` in Java, holds either a value or nothing. A result type, `Result<T, E>` in Rust and `Either` in Haskell, holds either a success value of type `T` or an error of type `E`. Because failure is part of the type, the compiler forces the caller to deal with both cases before using the value. Errors become ordinary data that can be passed, stored and transformed with the same tools as any other value.

use std::num::ParseIntError;

#[derive(Debug)]
enum AgeError {
    NotANumber(ParseIntError),
    OutOfRange(i64),
}

fn parse_age(s: &str) -> Result<u8, AgeError> {
    let n: i64 = s.trim().parse().map_err(AgeError::NotANumber)?;   // ? returns early on Err
    if (0..=130).contains(&n) {
        Ok(n as u8)
    } else {
        Err(AgeError::OutOfRange(n))
    }
}

fn main() {
    for input in ["42", " 7 ", "abc", "250"] {
        match parse_age(input) {
            Ok(age) => println!("{:>5?} -> age {}", input, age),
            Err(AgeError::NotANumber(e)) => println!("{:>5?} -> not a number ({})", input, e),
            Err(AgeError::OutOfRange(n)) => println!("{:>5?} -> {} is out of range", input, n),
        }
    }
}

"42" -> age 42
" 7 " -> age 7
"abc" -> not a number (invalid digit found in string)
"250" -> 250 is out of range

The `?` operator is the key to making result types pleasant. Applied to a `Result`, it returns the success value if there is one, and otherwise returns the error from the enclosing function immediately. It gives the brevity of exceptions, since intermediate functions need only a single character to propagate a failure, while keeping the failure visible in every signature on the way up. The error type is also an algebraic data type, so a `match` on it can be checked for exhaustiveness, as in lesson 3.

from dataclasses import dataclass
from typing import Generic, TypeVar, Callable, Union

T = TypeVar("T"); U = TypeVar("U"); E = TypeVar("E")

@dataclass(frozen=True)
class Ok(Generic[T]):
    value: T
@dataclass(frozen=True)
class Err(Generic[E]):
    error: E

Result = Union[Ok[T], Err[E]]

def bind(r, f):                         # chain a step that may fail
    return f(r.value) if isinstance(r, Ok) else r

def parse_int(s):
    return Ok(int(s)) if s.strip().lstrip("-").isdigit() else Err(f"not a number: {s!r}")
def check_range(n):
    return Ok(n) if 0 <= n <= 130 else Err(f"out of range: {n}")
def to_months(n):
    return Ok(n * 12)

for s in ["42", "abc", "250"]:
    r = bind(bind(parse_int(s), check_range), to_months)
    match r:
        case Ok(months): print(f"{s!r}: {months} months")
        case Err(msg):   print(f"{s!r}: error, {msg}")

'42': 504 months
'abc': error, not a number: 'abc'
'250': error, out of range: 250

The `bind` function chains steps that may fail: each step runs only if the previous one succeeded, and the first error passes through the rest untouched. This is the railway-oriented style: a success track and an error track, with each function able to switch to the error track. Python's ecosystem mostly uses exceptions, so this style is uncommon in Python libraries, but it is idiomatic in Rust, Haskell, Scala, F# and Swift, and it is a good fit wherever failures are expected and frequent, such as validating user input.

Validation, assertions and contracts

Some robustness techniques work in every paradigm. Validate inputs at the boundaries of your system, where data arrives from users, files or networks, and convert it into well-typed internal values once. Inside the boundary, code can then assume valid data. This is often summarized as parse, don't validate: rather than checking a string and passing the same string around, turn it into a value of a type that cannot be invalid, such as a `Date` or an `EmailAddress` object, so that later code never needs to recheck.

Assertions express assumptions that should never be false if the code is correct. `assert balance >= 0` documents an invariant and stops the program immediately if a bug breaks it. Assertions are for bugs, not for expected failures: Python removes them when run with the `-O` flag, so they must never be the only check on user input. Design by contract, developed by Bertrand Meyer for the Eiffel language, formalizes the idea with preconditions, which callers must satisfy, postconditions, which the function guarantees, and invariants, which every method preserves. These are the same notions you used in CMPUT-272 to prove programs correct.

from dataclasses import dataclass
import re

@dataclass(frozen=True)
class Email:
    """An email address that has already been checked; invalid instances cannot exist."""
    value: str
    def __post_init__(self):
        if not re.fullmatch(r"[^@\s]+@[^@\s]+\.[a-z]{2,}", self.value):
            raise ValueError(f"invalid email: {self.value!r}")

def send_welcome(to: Email) -> str:        # no need to re-validate: the type guarantees it
    return f"welcome mail queued for {to.value}"

def withdraw(balance, amount):
    assert amount > 0, "precondition: amount must be positive"
    new = balance - amount
    assert new >= 0, "postcondition: balance stays non-negative"
    return new

print(send_welcome(Email("ana@example.org")))
for raw in ["not-an-address"]:
    try:
        Email(raw)
    except ValueError as err:
        print("rejected at the boundary:", err)
print(withdraw(100, 30))
try:
    withdraw(20, 50)
except AssertionError as err:
    print("bug detected:", err)

welcome mail queued for ana@example.org
rejected at the boundary: invalid email: 'not-an-address'
70
bug detected: postcondition: balance stays non-negative