Back to prompts
Coding & DevelopmentPremiumintermediate
0.0

Error Handling Architecture — Stop Catching Generic Errors

Design a complete error handling system for your app. Custom error classes, proper logging, user-friendly messages, retry logic.

Copy & Paste this prompt
You are a reliability engineer who designs error handling systems for high-availability applications.

Design a complete error handling architecture for my application.

Language/Framework: [e.g., TypeScript/Node.js, Python/FastAPI, Go, etc.]
App type: [API / Web app / CLI / Library / Microservice]
External dependencies: [DATABASE, APIs, QUEUES, etc.]
Current error handling: [DESCRIBE — try/catch everywhere? No structure? Generic errors?]

Deliver:

1. ERROR TAXONOMY — Define a hierarchy of custom error classes:
   - Base error class with standard fields (code, message, context, timestamp, requestId)
   - Domain errors (BusinessLogicError, ValidationError, etc.)
   - Infrastructure errors (DatabaseError, ExternalAPIError, etc.)
   - Client errors vs Server errors (with proper HTTP status codes)
   Show the actual code for each class.

2. ERROR HANDLING MIDDLEWARE — Central error handler that:
   - Catches all unhandled errors
   - Logs with proper severity levels
   - Returns user-friendly messages (never stack traces in production)
   - Includes request correlation IDs
   - Distinguishes operational errors from programmer errors

3. RETRY STRATEGY — For each external dependency:
   - Should it retry? (Yes/No/Conditional)
   - Retry count, backoff strategy, circuit breaker threshold
   - What constitutes a retryable vs non-retryable error

4. LOGGING STANDARD — What to log at each level:
   - ERROR: [what goes here]
   - WARN: [what goes here]
   - INFO: [what goes here]
   Show a structured log example for each.

5. ERROR RESPONSE FORMAT — Standardized API error response shape with examples.

6. MONITORING ALERTS — Which errors should page someone at 3 AM vs. which can wait?
#error-handling#reliability#logging#architecture#best-practices

Works with

chatgptclaudecopilot

💡 Pro Tips

  • •Never expose stack traces or internal error details to users
  • •Log everything you need to debug, but never log sensitive data (passwords, tokens)
  • •If you catch an error and do nothing with it, you've just hidden a bug

✨ Example Output

ERROR TAXONOMY (TypeScript):
class AppError extends Error {
  constructor(
    public code: string,
    public statusCode: number,
    message: string,
    public isOperational = true,
    public context?: Record<string, unknown>
  ) { super(message); }
}
class ValidationError extends AppError {
  constructor(field: string, reason: string) {
    super('VALIDATION_ERROR', 400, `Invalid ${field}: ${reason}`);
  }
}

🧠 Why This Works

Ad-hoc error handling creates inconsistent user experiences and makes debugging nightmares. This prompt designs a complete error handling system—from throw to log to user message—with consistent patterns, proper error boundaries, and meaningful error taxonomy.

📅 When to Use This Prompt

Use when starting a new project and want error handling right from the beginning, when your current error handling is inconsistent across the codebase, or when users are seeing confusing errors and your logs aren't helping you debug.

🎯 What You'll Get

You'll receive a complete error handling architecture including custom error classes/types, error boundary patterns, logging strategy with structured context, user-facing message templates, and retry/recovery logic for transient failures.

🔗 Related Prompts

Coding & DevelopmentPremium

Error Message Humanizer

Transform cryptic error messages into user-friendly explanations and fixes.

debuggingerrorsdeveloper-experience
★4.5
beginner
Coding & Development

Senior Engineer Code Review

Get a thorough code review as if a senior engineer is looking at your PR — bugs, patterns, performance, and suggestions.

code-reviewbest-practicessecurity
★4.9
intermediate