Designing Errors Out of Your Go CLI

Most Go CLIs have too many error checks. Not because error handling is wrong — because the errors themselves are wrong. I read the Power of Go Tools by John Arundel. Based on his book, I audited a 50,000-line Go CLI for functions that return errors unnecessarily. The result: 10 functions refactored, 50+ if err != nil checks eliminated, and the remaining error checks now mean something. This is John Ousterhout's philosophy from A Philosophy of Software Design : don't handle errors better — design them out of existence . The Four Patterns I searched for four specific anti-patterns: Idempotent No-ops — returning an error for a state that already matches the desired outcome Empty-Set Errors — returning an error when a slice is empty instead of treating it as "no work to do" Recoverable Internals — returning an error when the function could make a sensible default decision Crash-Only Candidates — returning an error from initialization code where failure is truly fatal Here's what I found an