kid-sid/claude-spellbook/error-handling
Claude Code and agent skill by kid-sid/claude-spellbook
- community
Checking that the SKILL.md file is still in the repository.
Use when designing error hierarchies, propagating errors across service boundaries, implementing retry and backoff logic, writing structured error responses for APIs, or making error handling consistent across a Python, TypeScript, or Go codebase.
Install
npx vskill@latest install kid-sid/claude-spellbook/error-handlingSKILL.md
Error Handling
Patterns for structured errors, propagation, retries, and consistent failure surfaces across Python, TypeScript, and Go.
When to Activate
- Designing a custom exception or error hierarchy for a service
- Propagating errors across HTTP, gRPC, or queue boundaries
- Implementing retry logic with exponential backoff and jitter
- Writing consistent error responses for a REST or GraphQL API
- Distinguishing recoverable from unrecoverable errors
- Auditing a codebase for swallowed exceptions or bare
exceptblocks - Adding context to errors without losing the original cause
Error Classification
Classify errors before deciding how to handle them — the right response depends on what kind of failure occurred.
| Class | Examples | Handle by | |
|---|---|---|---|
| Validation | Missing field, bad format | Return 400 immediately — no retry | |
| Not found | Unknown ID, deleted resource | Return 404 — no retry | |
| Auth | Invalid token, expired session | Return 401/403 — no retry | |
| Transient | Network timeout, DB connection blip | Retry with backoff | |
| Dependency | Third-party API down, queue unavailable | Retry, then circuit-break | |
| Logic bug | Null deref, assertion failure | Log + alert — do not retry or swallow | |
| Rate limited | 429 from upstream | Retry after Retry-After header |
Custom Error Hierarchies
Python
TypeScript
Go
Adding Context Without Losing the Cause
Retry with Exponential Backoff and Jitter
Jitter prevents thundering herd when many callers retry simultaneously.
Structured API Error Responses
Every API error should include: machine-readable code, human-readable message, optional details for field-level problems.
Logging Errors
| Severity | When | Fields to include | |
|---|---|---|---|
ERROR | Unhandled or unexpected failures | message, stack, request_id, user_id | |
WARN | Handled but notable (retry succeeded, degraded mode) | message, attempt count | |
INFO | Expected failures returned to caller (404, 400) | code, path — no stack trace | |
DEBUG | Retry attempts, circuit state | attempt, delay, error message |
Red Flags
- Bare `except` / `catch (e) {}` — swallows the error entirely; always re-raise or handle explicitly.
- Retrying non-retryable errors — retrying a 400 or 404 wastes time and can amplify load; check error class before retrying.
- `raise Exception("something went wrong")` — generic base types give callers no way to branch; use typed domain errors.
- Logging and re-raising at every layer — logs the same error multiple times; propagate up and log once at the boundary.
- Using `%v` instead of `%w` in Go — breaks
errors.Is/errors.Asunwrapping; always use%wwhen wrapping. - Ignoring `err` in Go —
_ = fn()silently discards failures; use//nolint:errcheckonly with a documented reason. - No `request_id` in error responses — makes support and debugging impossible; always include a correlation ID.
- Returning 500 for client errors — masks bugs; map domain errors to the correct 4xx before they reach the handler.
- Retry without jitter — synchronized retries hammer a recovering dependency; always add random jitter.
Checklist
- [ ] Custom error types carry
code,message, and HTTPstatus— no rawException("string")at boundaries - [ ] Errors are wrapped with context at each layer (
from exc/{ cause }/%w) — original cause preserved - [ ] Error class determined before retrying — only
TRANSIENTerrors retried, never validation or auth errors - [ ] Retry uses exponential backoff with jitter — no fixed-interval loops
- [ ] Global error handler present — no unhandled errors reaching the framework default
- [ ] API error responses include
code,message, andrequest_id— consistent shape across all endpoints - [ ] Errors logged once at the top boundary — not re-logged at every layer
- [ ]
INFOused for expected 4xx,ERRORfor unexpected 5xx — no stack traces in 404 logs - [ ] Go functions never ignore
errorreturn values without a documented reason - [ ] Circuit breaker or fallback present for calls to external dependencies
Security
- Security scanPassed, 100 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/error-handling/skill.md
Popularity
- Repository stars
- 186
- Repository forks
- 15
- 7-day trend score
- 26
Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/kid-sid/claude-spellbook/error-handling)