home / skills / shipshitdev / library / error-handling-expert

error-handling-expert skill

/bundles/backend/skills/error-handling-expert

This skill helps you implement robust error handling patterns, logging, and recovery strategies across React, Next.js, and NestJS applications.

npx playbooks add skill shipshitdev/library --skill error-handling-expert

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
2.3 KB
---
name: error-handling-expert
description: Expert in error handling patterns, exception management, error responses, logging, and error recovery strategies for React, Next.js, and NestJS applications
---

# Error Handling Expert Skill

Expert in error handling patterns, exception management, error responses, logging, and error recovery strategies for React, Next.js, and NestJS applications.

## When to Use

- Implementing error handling
- Creating exception filters
- Designing error responses
- Setting up error logging
- Implementing error recovery
- Handling async errors
- Creating error boundaries
- Implementing retry logic

## Project Context Discovery

Before providing guidance:

1. Check `.agents/SYSTEM/ARCHITECTURE.md` for error patterns
2. Review existing exception filters
3. Check for error monitoring (Sentry, Rollbar)
4. Review logging libraries (Winston, Pino)

## Core Principles

### Error Types

**Application Errors:** 400, 401, 403, 404, 409, 422
**System Errors:** 500, 502, 503, 504

### Error Response Format

```typescript
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Validation failed",
    "details": [...],
    "timestamp": "2025-01-01T00:00:00Z",
    "path": "/api/users",
    "requestId": "req-123456"
  }
}
```

## Quick Patterns

### NestJS Exception Filter

```typescript
@Catch()
export class AllExceptionsFilter implements ExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost) {
    // Log, format, respond
  }
}
```

### React Error Boundary

```typescript
class ErrorBoundary extends React.Component {
  componentDidCatch(error, errorInfo) {
    // Log to monitoring
  }
}
```

### Retry with Backoff

```typescript
async function retryWithBackoff<T>(fn, maxRetries = 3): Promise<T>
```

## Best Practices

- User-friendly messages, no sensitive info
- Log all errors with context
- Integrate error monitoring (Sentry)
- Implement retry logic and circuit breakers
- Provide fallback values
- Test error cases

## Recovery Strategies

1. **Retry Logic** - Exponential backoff
2. **Circuit Breaker** - Prevent cascade failures
3. **Fallback Values** - Graceful degradation

---

**For complete exception filter implementations, custom exceptions, validation pipe setup, error boundaries, circuit breaker pattern, logging integration, and database/API error patterns, see:** `references/full-guide.md`

Overview

This skill is an error-handling expert for React, Next.js, and NestJS applications. It provides hands-on guidance for exception management, structured error responses, logging, and recovery strategies. The goal is to help teams implement robust, observable, and user-friendly error handling across frontend and backend stacks.

How this skill works

The skill inspects project patterns, existing exception filters, and logging/instrumentation to recommend targeted improvements. It suggests concrete implementations: NestJS exception filters, React error boundaries, standardized error response shapes, retry-with-backoff utilities, and circuit breaker strategies. Recommendations include logging context, integration with monitoring (Sentry/Rollbar), and testing approaches for error scenarios.

When to use it

  • When designing API error formats and HTTP status mapping for NestJS
  • When adding error boundaries or centralized error handling in React/Next.js
  • When integrating error monitoring and structured logging
  • When implementing retry logic, exponential backoff, or circuit breakers
  • When reviewing production incidents to harden error recovery paths

Best practices

  • Return standardized error objects with code, message, details, timestamp, path, and requestId
  • Avoid leaking sensitive info; surface user-friendly messages and internal details only in logs
  • Log every error with request context, user id, and stack traces to a centralized store
  • Use retry with exponential backoff for transient failures and circuit breakers for unstable services
  • Implement graceful fallbacks on the frontend and thorough tests for error paths

Example use cases

  • Create a NestJS AllExceptionsFilter that logs, maps known exceptions to codes, and returns a consistent JSON error shape
  • Wrap critical UI components in a React ErrorBoundary that logs to Sentry and renders a fallback UI
  • Add a retryWithBackoff utility for flaky third-party API calls with configurable maxRetries and jitter
  • Introduce a circuit breaker around a slow microservice to avoid cascading failures
  • Standardize 4xx validation errors vs 5xx system errors and document mapping for clients

FAQ

What should an API error response include?

Include a machine-readable code, a human-friendly message, optional details for validation errors, a timestamp, request path, and a requestId for correlation.

When should I use retries vs circuit breakers?

Use retries for short-lived, transient errors (with exponential backoff). Use circuit breakers when a downstream service is repeatedly failing or slow to prevent resource exhaustion.

How do I avoid exposing sensitive information in errors?

Return generic messages to clients and record full details in secure logs. Strip stack traces and internal hints from public responses.