Errors As Values Vs Exceptions

The Design Choice

Languages choose different ways to model failure. Go returns error values. Rust uses Result for recoverable failure and panic for unrecoverable or bug-like paths. Java and C# use exceptions heavily, with Java also distinguishing checked and unchecked exceptions. Python uses exceptions as a central control and error-reporting mechanism. Swift uses throw, try, and typed result patterns in libraries.

The choice affects API shape. Error values make failure visible in signatures and ordinary control flow. Exceptions separate the normal return value from exceptional control flow, which can keep happy paths compact but move failure paths away from the call site.

Practical Tradeoffs

Explicit error values are strong when callers should handle failure locally, when APIs cross process or language boundaries, and when retries, diagnostics, and fallback paths are part of normal operation.

Exceptions are strong when failures should unwind through several layers, when cleanup is reliably scoped, and when framework or platform conventions expect exception handling.

Mixed models are common. Many systems use status values for expected domain outcomes, exceptions or panics for bugs and invariants, and process-level exits for unrecoverable startup or configuration failure.

Watch Points

Ask whether failure is visible in the type, whether cleanup runs, whether stack traces are preserved, whether errors carry enough context, and whether error paths are tested. Avoid swallowing exceptions, ignoring error values, converting rich errors into strings too early, or treating panics as normal control flow.

Related Concepts

Error handling intersects with RAII And Deterministic Cleanup, Null Safety, Testing Cultures, and Foreign Function Interface.