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…