codingarchitecture

Error Handling Strategy Guide

Designs an error handling architecture with custom error classes, logging, user messages, and recovery strategies.

Prompt

You are a software architect specialising in resilient [type of application, e.g. 'Node.js REST API' or 'React SPA with API backend'] systems for [industry] companies. Design a comprehensive error handling strategy. The target audience is the engineering team, and the goal is consistent, debuggable error behaviour. Format the output as structured sections with code examples: (1) a custom error class hierarchy (for example, a base AppError class with subclasses such as ValidationError, NotFoundError, AuthenticationError, RateLimitError, and ExternalServiceError), (2) an error response format: consistent JSON structure with error code, message, details, and request ID, (3) a global error handler/middleware that catches all errors, (4) logging strategy: what to log at each level (error, warn, info) with structured logging examples, (5) error handling for 3 common scenarios (database query failure, external API timeout, and invalid user input), showing the complete flow, (6) retry strategy: which errors to retry, backoff algorithm, max attempts, (7) monitoring: what alerts to set up and at what thresholds. Language: [language/framework]. You must ensure sensitive data is never exposed in error responses. Avoid generic catch-all handlers that swallow errors silently. Only retry idempotent operations.

Why this prompt works

The custom error class hierarchy (base AppError plus subclasses for ValidationError, NotFoundError, AuthenticationError, RateLimitError, ExternalServiceError) is the foundation everything else hangs off. Without a typed error hierarchy, error handling becomes a series of stringly-typed checks, and the global error handler can't route consistently. The structured JSON error response format means clients can distinguish error categories programmatically rather than parsing messages. The retry strategy section ('only retry idempotent operations') is the kind of constraint that prevents the most common error-handling bug: blindly retrying a payment request that already succeeded.

When to reach for it

You're starting a new service and want error handling architected upfront rather than retrofitted later.
You're auditing an existing codebase whose error handling has grown organically and want a consistent target spec.
You're scaling a team and need junior engineers to follow the same error patterns as senior ones.
You're moving from an unstructured try/catch culture to a typed error culture and want the migration target documented.

How to customise it

The application type field is non-trivial. A REST API and a SPA have different error surfaces, and a job queue has different concerns again. Be specific. The language and framework input shapes the syntax; if you're using a framework with built-in error patterns (NestJS, Spring), tell the model to align with those rather than invent a parallel hierarchy. For services that handle payments or other irreversible operations, add 'include idempotency-key handling' explicitly; the model touches on idempotency in retry strategy but doesn't always cover the request-level pattern.

What good output looks like

Code examples in the chosen language for the error hierarchy, a global error middleware, structured logging with examples at each level, error handling flows for three named scenarios (DB failure, API timeout, invalid input), retry strategy with backoff math, and monitoring alert thresholds. Sensitive data filtering is built into the error response shape. Length around 1,500 to 3,000 words depending on language verbosity.

Watch out for

The model can suggest catching too broadly in middleware ('catch all errors and return 500'), which loses the type information you spent effort building. Insist on routing AppError subclasses to specific status codes (4xx for client errors, 5xx for server errors) and only treating unknown errors as 500. The monitoring thresholds are heuristic; calibrate them after you have real traffic data rather than trusting the suggested numbers.

error handlingarchitectureloggingmiddlewarebest practicesChatGPT / Claude