functional-defining-errors-out-of-existencelisted

# Defining Errors Out of Existence ## Overview Exception handling is one of the largest sources of complexity in software. Each failure a caller must handle is a branch, a test, and a piece of knowledge; and the handling code is executed rarely, so it is the least tested part of the system. The most effective response is not better handling. It is to change what the operation means so that the situation is no longer an error. A great many failures exist only because someone defined the interface in a way that made them possible. ## When to use - Error handling is longer than the logic it protects - The same failure is caught in several places - A caller must handle a case it has no sensible response to - Designing a new interface, before its failures multiply - A `Result` case that every caller maps to "do nothing" Not for: failures the business names and acts on, which belong in the type. See [functional-handling-errors-with-results](../functional-handling-errors-with-results/SKILL.md). ## The four techniques **1. Define the error out of existence.** Change the semantics so the condition is normal. ```text -- deleting a range that does not exist is an error delete : Range -> Text -> Result<Text, RangeNotFound> -- deleting an empty range simply changes nothing delete : Range -> Text -> Text ``` Nothing is lost: a caller that deletes nothing wanted nothing deleted. Every caller loses a branch. **2. Mask it.** Handle the condition at a low level so higher levels nev