Error Handling Strategy Prompt Template
Design a comprehensive error handling strategy with custom error classes, logging approach, and user-facing messages.
The Prompt
ROLE: You are a senior platform engineer who designs error handling systems that help developers debug production issues in minutes rather than hours — you know that how you handle errors is what separates professional software from scripts that happen to work.
CONTEXT: You are designing a comprehensive error handling strategy for an application. Error handling has three audiences: the end user (needs a clear, non-technical message), the developer (needs context to debug), and the monitoring system (needs structured data to alert and aggregate). Most error handling serves only one of these and fails the other two.
TASK: Design a complete error handling strategy for the application type and language described below.
RULES:
• Classify all error types into 3 categories: Fatal (unrecoverable, crash or restart), Recoverable (can be handled gracefully), and Validation (user input errors)
• The custom error class hierarchy must be minimal — enough to distinguish error types without creating a class-per-error-message antipattern
• The logging strategy must specify: what to log (not everything — be selective), what format (structured JSON for production), and what NOT to log (PII, credentials, full request bodies)
• User-facing error messages must be separate from internal error details — never expose stack traces or internal IDs to users
• Include a global error handler pattern that catches unhandled rejections and exceptions
CONSTRAINTS: Use [LANGUAGE_FRAMEWORK]. Code examples must be production-ready. Error messages to users must be helpful without being technical: "Something went wrong with your payment — your card was not charged" not "Error 500: database connection timeout in payments_service".
EDITABLE VARIABLES:
• [APPLICATION_TYPE] — e.g. REST API, Next.js app, CLI tool, background worker
• [LANGUAGE_FRAMEWORK] — e.g. TypeScript/Express, Python/FastAPI, Go
• [MONITORING_TOOL] — e.g. Sentry, Datadog, CloudWatch, or "not yet decided"
• [SENSITIVE_DATA] — what sensitive data the application handles (to inform what NOT to log)
OUTPUT FORMAT:
**Error Classification:**
[Fatal / Recoverable / Validation — description and examples of each]
**Custom Error Class Hierarchy:**
```[language]
// Error classes with properties
```
**Global Error Handler:**
```[language]
// Catch-all handler for unhandled errors
```
**Logging Strategy:**
- What to log: [structured fields]
- What NOT to log: [PII/credential list]
- Log level mapping: [Error type → log level]
**User-Facing Messages:**
[3 examples: technical error → user message]
**Monitoring Integration:**
[How to connect to [MONITORING_TOOL] with enriched context]
QUALITY BAR: When an error occurs in production at 3am, the on-call engineer should be able to identify the cause, the affected users, and the remediation path from the error log alone — without reading the code.
Make it specific to you
PromptITIN asks a few questions and builds a version tailored to your use case.
How to use this template
1
Copy the template
Click the copy button to grab the full prompt text.
2
Fill in the placeholders
Replace anything in [BRACKETS] with your specific details.
3
Paste into any AI tool
Works with ChatGPT, Claude, Gemini, Cursor, and more.
4
Or enhance with AI
Sign in to PromptITIN and let AI tailor the prompt to your exact situation in seconds.
Why this prompt works
The three-audience framing (user / developer / monitoring system) forces the AI to design error handling that serves all three, rather than the common mistake of writing errors as if the only reader is the developer who wrote the code. The 3am quality bar is concrete and eliminates theoretical over-engineering.
Tips for best results
- Define your error handling strategy before writing application code — retrofitting it into an existing codebase is painful and often done incompletely
- The 'what NOT to log' section is the most legally important for GDPR and CCPA compliance — review it with your data protection officer if you handle EU or California user data
- Centralise error handling in one module and import it everywhere — distributed error handling strategies drift and become inconsistent over time
- Add error boundary components (React) or middleware (Express) as your first application code after defining the strategy — it ensures every route and component is covered from day one