freemo
d9e5668cec
Fixes and improvements from exhaustive audit: Consistency fixes in SKILL.md: - 'Pipe & Filter' → 'Pipe and Filter' (one stray '&' found and corrected) - 'Singleton for factory instance' → clarified to 'register factory as singleton-scoped via DI container' (less misleading wording) - Documentation Format section updated with note that SKILL.md itself is the authoritative source for related-pattern combinations Coverage fix — Related Patterns sections: - Added '## Related Patterns' to ALL 94 pattern files (was 0/94) - Each section lists 3–6 related patterns with relationship descriptions - Covers: why they're related, when to prefer one vs the other, and which are often confused SOLID principles → Creational → Structural → Behavioral → Architectural → Concurrency → Functional → Resilience → Data Access → Messaging → Testing → Error Handling → Microservice — all 13 categories covered Code verification: - Python: 0 failures (all 85 testable blocks pass) - Go: 0 failures (all 76 testable blocks pass) - JavaScript: 0 failures (all 78 testable blocks pass) - All 239 code blocks verified correct after edits Final skill state: - 108 files, 36,524 lines across 13 reference categories - 94/94 pattern files have Related Patterns sections - 2,815-line SKILL.md with 67 decision trees, 23 scenarios, 0 broken references, 0 naming inconsistencies
Error Handling Patterns
Overview
Error handling patterns provide structured approaches to detecting, reporting, and recovering from failures. Good error handling makes systems robust, debuggable, and predictable. Poor error handling hides bugs, corrupts state, and produces cascading failures.
Pattern Comparison
| Pattern | Purpose | Mechanism | Key Benefit |
|---|---|---|---|
| Guard Clause | Validate inputs at entry, bail early | Early return / raise | Flat, readable control flow |
| Result Type | Encode success-or-error in return value | Result<T, E> / Either |
Compiler-enforced error handling |
| Fail Fast | Detect errors immediately at boundaries | Validate + abort on first error | Prevents silent corruption |
| Exception Hierarchy | Organize exceptions in a meaningful tree | Class inheritance | Granular catch + categorization |
When to Use Which
- Validating function arguments at the top? Use Guard Clause to reject bad input early.
- Returning errors without exceptions? Use Result Type for explicit success/failure.
- Want to crash immediately on invalid state? Use Fail Fast to prevent downstream corruption.
- Need categorised, catchable errors? Use Exception Hierarchy for domain-specific error trees.
Relationships Between Patterns
- Guard Clause is often the first check inside a function; it may raise exceptions from an Exception Hierarchy or return a Result Type.
- Fail Fast philosophy motivates Guard Clauses — both prefer early detection over late recovery.
- Result Type and Exception Hierarchy are alternative error-propagation mechanisms: Result is explicit in the type system; exceptions use control flow.
- Languages like Go and Rust strongly favour Result Type; Java and Python traditionally use Exception Hierarchy.
Design Guidelines
- Be explicit — callers should not be surprised by errors.
- Fail close to the source — detect problems where they originate.
- Provide context — error messages should include what went wrong, why, and what to do.
- Don't swallow errors — empty
except:/catchblocks hide bugs. - Match error granularity to recovery needs — don't over-categorise if callers won't distinguish.