Define Errors Out of Existence

Reduce the number of places that must handle errors by redefining the semantics so that the error condition simply does not arise, instead of detecting and reporting it everywhere.

Why it Matters

Exception and special-case handling is one of the largest sources of complexity, because every exception multiplies the paths a developer must reason about. Eliminating a class of errors removes that branching entirely rather than just managing it.

Signals

• Many callers wrap the same operation in the same try/catch or null check.
• An API throws for a condition that could reasonably be treated as normal (e.g. "delete a key that isn't there").

Benefits

Fewer exceptional paths, smaller interfaces, and less defensive code at every call site. The remaining errors are the ones that genuinely deserve attention.

Risks

Hiding errors that callers actually need to know about is worse than reporting them. The aim is to redefine away non-errors, not to silently swallow real failures.

Tensions

Competes with "fail fast / be explicit" guidance. The resolution is about which conditions are genuinely exceptional: redefine the ones that aren't, surface (or crash on) the ones that are. Related techniques include exception masking, aggregation, and simply crashing on unrecoverable states.

Examples

Defining "delete a nonexistent item" as a no-op that returns normally removes an exception every caller would otherwise handle. Returning an empty range instead of throwing on an out-of-bounds substring request does the same.