Skip to content
Back to skills

Error Handling Patterns

ASecurity

Structured error types, recovery strategies, and boundary-aware error handling. Prevents raw string errors, leaked stack traces, and silent failures.

  • 7 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added May 27, 2026
developmenttypescriptapi

Works with

  • api

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add Vimalk0703/shipworthy --skill error-handling-patterns --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Error Handling Patterns?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Error Handling Patterns
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/vimalk0703-error-handling-patterns/badge)](https://www.skillsdirectory.com/skills/vimalk0703-error-handling-patterns)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: error-handling-patterns
description: Structured error types, recovery strategies, and boundary-aware error handling. Prevents raw string errors, leaked stack traces, and silent failures.
invoke_when: Use when writing try/catch blocks, defining error types, creating API error responses, or handling async operations that can fail.
---

# Error Handling Patterns

## Core Principles

1. **Errors are data, not strings** — use structured error types with codes, messages, and context
2. **Handle at boundaries** — catch at architectural boundaries (API, service, data layer), not everywhere
3. **User-facing errors are safe** — never expose stack traces, internal paths, or implementation details
4. **Errors are loggable** — every error carries enough context to debug without reproducing
5. **Recovery is explicit** — every catch block states its recovery strategy

## Structured Error Pattern

```typescript
class AppError extends Error {
  constructor(
    public code: string,
    message: string,
    public statusCode: number = 500,
    public context?: Record<string, unknown>
  ) {
    super(message);
    this.name = 'AppError';
  }
}
throw new AppError('USER_NOT_FOUND', 'User does not exist', 404, { userId });
```

## Boundary Error Handling

- **API Layer**: Catch all, map to HTTP status, return safe JSON, log full error with correlation ID
- **Service Layer**: Catch specific expected errors, add context, re-throw as AppError
- **Data Layer**: Catch DB-specific errors, translate to domain errors (duplicate key → CONFLICT)

## Recovery Strategies

Every catch block must implement one of:
1. **Retry** — transient failures (network, rate limits). Exponential backoff.
2. **Fallback** — degrade gracefully (cache, default value)
3. **Propagate** — re-throw with added context for the next boundary
4. **Fail fast** — unrecoverable. Log, clean up, terminate the operation.

## Anti-Patterns

- `catch (e) {}` — silent swallowing. NEVER.
- `catch (e) { console.log(e) }` — logged but not handled. What's the recovery?
- Catching too broadly at the wrong layer
- Wrapping every function call in try/catch

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.