handling-errors-with-resultslisted

# Handling Errors With Results ## Overview An error that a caller is expected to handle is part of the function's contract, so it belongs in the function's type. `Result<T, E>` puts it there: the function returns either a success or a named failure, and no caller can forget that failure exists. Composing such functions is the only mechanic worth learning. A chain of steps that each may fail forms two tracks: the success track runs through every step, and the first failure diverts to the failure track and skips the rest. Once that shape is in place, error handling stops being scattered defensive code and becomes part of the pipeline's structure. ## When to use - Designing what a function returns when it can fail - Exceptions are thrown in one module and caught in another - A form must report every invalid field, not just the first - Deciding what an error type should contain - A pipeline step can fail and the failure must reach the caller Not for: failures that can be removed by design, which is [defining-errors-out-of-existence](../defining-errors-out-of-existence/SKILL.md). ## Core rules 1. **Expected failures are values.** If a caller should act on it, return it. Reserve exceptions for programmer bugs and unrecoverable conditions. 2. **Name the failures in the domain's words.** `QuoteExpired`, not `Error500` or a bare string. 3. **One error choice type per workflow.** Steps keep narrow error types and are lifted at composition, so callers match on one th