Agent skill · software engineering · erichowens
error-handling-patterns
Design error handling strategies for TypeScript and Python applications — exception hierarchies, Result/Either types, retry patterns, error boundaries, and structured error logging. Use when
Why this skill is useful
Provides domain-specific strategies for error handling in TypeScript and Python that the AI wouldn't reliably generate on its own.
What it needs
About 6k tokens when loaded. Last updated 2026-07-14. 180 stars on the source repository.
What this skill does
Error Handling Patterns Design error handling strategies that make failures explicit, recoverable, and debuggable. The central skill is matching error handling style to error semantics: not all errors are equal, and treating them equally produces systems that are equally bad at handling all of them. When to Use ✅ Use for: Choosing between exceptions, Result types, or error codes for a domain Designing typed error hierarchies in TypeScript or Python Implementing retry logic with backoff, jitter, and circuit breaking Building React error boundaries and graceful degradation Structuring error information for both users and developers Python exception chaining and cause / context semantics ❌ NOT for: Debugging a specific runtime error (use debugger or domain skill) Logging pipeline infrastructure (use observability skill) APM/monitoring configuration (use site-reliability-engineer skill) Writing tests for error paths (use vitest-testing-patterns skill) --- Core Decision: Exception vs Result Type vs Error Code Rules of thumb: Library code: prefer Result types — never force callers to handle your exceptions Application code: typed exception hierarchies work well; errors are exceptional CLI / scripts: error codes are fine; the user is the error boundary Async workers: Result types or structured error objects with retry metadata --- Error Classification Classify every error along two axes before deciding how to handle it: Transient (retry may succeed) Permanent (retry won't help) --- --- --- User-actionable Rate limit, quota exceeded Invalid input, unauthorized System-actionable Network timeout, DB connection Data corruption, schema mismatch This classification determines: Whether to retry (transient only) What to show the user (user-actionable → message; system → generic error + tracking ID) Whether to alert on-call (system permanent → page; transient spikes → alert) --- Should This Error Be Retried? Consult references/retry-patterns.md for backoff formulas, jitter strategi …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills erichowens/error-handling-patterns