
Error Handling
Apply consistent typed-error, retry, and boundary patterns in TypeScript, Python, and Go so agents stop shipping silent failures and vague API responses.
Overview
Error Handling is a journey-wide agent skill that teaches robust typed-error, retry, and boundary patterns across TypeScript, Python, and Go—usable whenever a solo builder needs to harden code before shipping or during i
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill error-handlingWhat is this skill?
- 5 core principles: fail fast, typed errors, separate user and developer messages, never swallow catches, errors as API c
- Language patterns for TypeScript/JavaScript, Python, and Go including typed error hierarchies
- Guidance for retries, circuit breakers, and unreliable external dependencies
- Activation triggers for exception design, endpoint review, and cascading-failure debugging
- User-facing error copy vs structured server-side logging context
- 5 core error-handling principles
- Patterns cover TypeScript, Python, and Go
Adoption & trust: 1.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent adds try/catch blocks that hide failures, returns generic 500s, or retries without limits so users see vague errors while logs lack actionable context.
Who is it for?
Builders implementing APIs, workers, or CLIs who want one checklist for errors that survives code review and on-call.
Skip if: Greenfield spikes where throwing fast and refactoring later is explicit, or pure frontend UI polish with no failure paths yet.
When should I use this skill?
Designing error types, adding retries or circuit breakers, reviewing APIs for missing handling, implementing user-facing messages, or debugging cascading failures.
What do I get? / Deliverables
Modules gain documented error types, clear client-facing messages, and logging or rethrow behavior that makes API failures predictable and debuggable.
- Typed error class hierarchy
- Documented client-visible error codes
- Retry and circuit-breaker guidance applied to dependencies
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Define AppError subclasses and status codes before exposing new REST routes.
Walk endpoints to ensure every failure path returns a documented code and logs context.
Trace a cascade where swallowed promises masked the root dependency timeout.
Sketch error responses for a thin MVP API so UX copy is decided early.
Align support macros with stable error codes customers actually see in the app.
How it compares
Use as procedural quality guidance instead of ad-hoc 'add a try/catch' chat advice that ignores API contracts and circuit breaking.
Common Questions / FAQ
Who is error-handling for?
Solo and indie developers using coding agents on multi-language backends who need consistent error design without reading three separate style guides.
When should I use error-handling?
During Build when defining service errors; during Ship review before launch; during Operate when debugging cascades; during Validate when stubbing APIs that must return structured failure codes.
Is error-handling safe to install?
It is pattern documentation without shell or network execution by default; review the Security Audits panel on this page before installing from any third-party skill pack.
SKILL.md
READMESKILL.md - Error Handling
# Error Handling Patterns Consistent, robust error handling patterns for production applications. ## When to Activate - Designing error types or exception hierarchies for a new module or service - Adding retry logic or circuit breakers for unreliable external dependencies - Reviewing API endpoints for missing error handling - Implementing user-facing error messages and feedback - Debugging cascading failures or silent error swallowing ## Core Principles 1. **Fail fast and loudly** — surface errors at the boundary where they occur; don't bury them 2. **Typed errors over string messages** — errors are first-class values with structure 3. **User messages ≠ developer messages** — show friendly text to users, log full context server-side 4. **Never swallow errors silently** — every `catch` block must either handle, re-throw, or log 5. **Errors are part of your API contract** — document every error code a client may receive ## TypeScript / JavaScript ### Typed Error Classes ```typescript // Define an error hierarchy for your domain export class AppError extends Error { constructor( message: string, public readonly code: string, public readonly statusCode: number = 500, public readonly details?: unknown, ) { super(message) this.name = this.constructor.name // Maintain correct prototype chain in transpiled ES5 JavaScript. // Required for `instanceof` checks (e.g., `error instanceof NotFoundError`) // to work correctly when extending the built-in Error class. Object.setPrototypeOf(this, new.target.prototype) } } export class NotFoundError extends AppError { constructor(resource: string, id: string) { super(`${resource} not found: ${id}`, 'NOT_FOUND', 404) } } export class ValidationError extends AppError { constructor(message: string, details: { field: string; message: string }[]) { super(message, 'VALIDATION_ERROR', 422, details) } } export class UnauthorizedError extends AppError { constructor(reason = 'Authentication required') { super(reason, 'UNAUTHORIZED', 401) } } export class RateLimitError extends AppError { constructor(public readonly retryAfterMs: number) { super('Rate limit exceeded', 'RATE_LIMITED', 429) } } ``` ### Result Pattern (no-throw style) For operations where failure is expected and common (parsing, external calls): ```typescript type Result<T, E = AppError> = | { ok: true; value: T } | { ok: false; error: E } function ok<T>(value: T): Result<T> { return { ok: true, value } } function err<E>(error: E): Result<never, E> { return { ok: false, error } } // Usage async function fetchUser(id: string): Promise<Result<User>> { try { const user = await db.users.findUnique({ where: { id } }) if (!user) return err(new NotFoundError('User', id)) return ok(user) } catch (e) { return err(new AppError('Database error', 'DB_ERROR')) } } const result = await fetchUser('abc-123') if (!result.ok) { // TypeScript knows result.error here logger.error('Failed to fetch user', { error: result.error }) return } // TypeScript knows result.value here console.log(result.value.email) ``` ### API Error Handler (Next.js / Express) ```typescript import { NextRequest, NextResponse } from 'next/server' function handleApiError(error: unknown): NextResponse { // Known application error if (error instanceof AppError) { return NextResponse.json( { error: { code: error.code, message: error.message, ...(error.details ? { details: error.details } : {}), }, }, { status: error.statusCode }, ) } // Zod validation error if (error instanceof z.ZodError) { return NextResponse.json( { error: { code: