Coding & DevelopmentPremiumintermediate

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}`);
  }
}