Error Handling Audit | AI Toolkit

Error handling is the part of the codebase nobody reviews carefully. Errors get caught and logged, caught and ignored, or not caught at all. This technique uses Claude Code to systematically audit how errors flow through your system and find the gaps.

The prompt

Audit the error handling in this codebase. Read the key modules and trace how errors propagate.

## What to look for

### Silent failures
Code that catches errors and does nothing, or catches and only logs:
- Empty catch blocks
- catch blocks that log but don't re-throw or return error state
- .catch(() => {}) on promises
- try/catch around code that should crash if it fails

### Missing boundary validation
External inputs that aren't validated before use:
- API request bodies used without validation
- URL parameters used directly in queries or file paths
- Environment variables accessed without fallback or existence check
- User input rendered without sanitization

### Inconsistent error patterns
Different parts of the codebase handling errors differently:
- Some functions throw, others return null, others return { error }
- Some API routes return 500 with details, others return 200 with error in body
- Inconsistent error response shapes

### Error information leakage
Errors that expose internal details to users:
- Stack traces in API responses
- Database error messages shown in UI
- File paths or internal IDs in error messages

## Output format

For each finding:
1. **Location**: file and line
2. **Category**: silent failure / missing validation / inconsistency / leakage
3. **Risk**: what could go wrong in production
4. **Fix**: concrete change (don't just say "add error handling")

Group findings by category, not by file. This reveals systemic patterns.

When to use it

Before a production launch or major release
After inheriting a codebase you didn't build
When debugging intermittent failures (often caused by silent error swallowing)
As part of a quarterly code health review

Why "group by category" matters

Grouping by file produces a laundry list. Grouping by category reveals patterns: "We have 12 silent failures, all in our database layer" tells you something actionable — the database layer needs an error handling convention. "We have 3 issues in file A and 2 in file B" tells you nothing.

Tips

Start with the boundaries: API routes, file I/O, database queries, external service calls. These are where errors originate. Internal pure functions rarely need error handling.
The most dangerous finding is usually "catch and log" — code that swallows errors and continues executing with invalid state. These cause the bugs that are hardest to reproduce.
Don't fix everything at once. Pick the highest-risk category and address it systematically. Consistent error handling in one layer is better than scattered fixes everywhere.