This skill audits error handling with zero tolerance for silent failures and inadequate recovery. The goal is to ensure every error is properly surfaced, logged, and actionable.
Context to Gather
Before hunting, read:
- All files with try-catch blocks, error handlers, fallback logic
- Error handling patterns used elsewhere in the codebase
- Logging utilities and error ID constants if they exist
Core Principles
- Silent failures are unacceptable - Any error that occurs without proper logging and user feedback is a critical defect
- Users deserve actionable feedback - Every error message must tell users what went wrong and what they can do about it
- Fallbacks must be explicit and justified - Falling back to alternative behavior without user awareness is hiding problems
- Catch blocks must be specific - Broad exception catching hides unrelated errors and makes debugging impossible
- Mock/fake implementations belong only in tests - Production code falling back to mocks indicates architectural problems
Review Process
1. Identify All Error Handling Code
Systematically locate:
- All try-catch blocks (or try-except in Python, Result types in Rust, etc.)
- All error callbacks and error event handlers
- All conditional branches that handle error states
- All fallback logic and default values used on failure
- All places where errors are logged but execution continues
- All optional chaining or null coalescing that might hide errors
2. Scrutinize Each Error Handler
For every error handling location, ask:
Logging Quality:
- Is the error logged with appropriate severity?
- Does the log include sufficient context (what operation failed, relevant IDs, state)?
- Would this log help someone debug the issue 6 months from now?
User Feedback:
- Does the user receive clear, actionable feedback about what went wrong?
- Does the error message explain what the user can do to fix or work around the issue?
- Is the error message specific enough to be useful, or is it generic and unhelpful?
Catch Block Specificity:
- Does the catch block catch only the expected error types?
- Could this catch block accidentally suppress unrelated errors?
- List every type of unexpected error that could be hidden by this catch block
Fallback Behavior:
- Is there fallback logic that executes when an error occurs?
- Does the fallback behavior mask the underlying problem?
- Would the user be confused about why they're seeing fallback behavior instead of an error?
Error Propagation:
- Should this error be propagated to a higher-level handler instead of being caught here?
- Is the error being swallowed when it should bubble up?
3. Check for Hidden Failures
Look for patterns that hide errors:
- Empty catch blocks (absolutely forbidden)
- Catch blocks that only log and continue
- Returning null/undefined/default values on error without logging
- Using optional chaining (?.) to silently skip operations that might fail
- Fallback chains that try multiple approaches without explaining why
- Retry logic that exhausts attempts without informing the user
Output Format
For each issue found, provide:
- Location: File path and line number(s)
- Severity: CRITICAL (silent failure, broad catch), HIGH (poor error message, unjustified fallback), MEDIUM (missing context, could be more specific)
- Issue Description: What's wrong and why it's problematic
- Hidden Errors: List specific types of unexpected errors that could be caught and hidden