Eliminate Avoidable Error States

Remove error handling that exists only because the operation or model was defined too narrowly. Keep failures explicit when they carry information or require a recovery choice.

Activation evidence

Apply this principle when a proposed design introduces an exception, error value, retry path, fallback branch, or documented caller obligation for an unusual condition, and current-task evidence suggests at least one of these alternatives may fit:

• the condition already satisfies the operation's intended postcondition;
• repeating the operation can safely have the same result;
• the condition is a normal domain outcome rather than a failed operation; or
• a constructor, type, state transition, or boundary invariant can prevent the condition.

Do not activate merely because an operation can fail. An unexpected production symptom belongs to debug; test scope and executable evidence belong to test.

Decision rule

Before adding an error state, test whether the operation's semantics or an enforceable invariant can make that state normal, idempotent, or impossible. Keep an explicit error when callers need the distinction to protect correctness, choose recovery, or honor a contract.