Audit error handling and logging consistency across a module
Category: Audit · Updated 2026-09-22 · Tools: Both
Use this when a service has grown under multiple contributors and error handling feels inconsistent — some paths log and swallow, others log and re-throw, others do neither. Good groundwork before actually standardizing anything, since applying a fix blind risks changing behavior that a caller depends on. Medium usage.
Full prompt
Survey how errors are handled across <module/service path>: for each catch block or error-returning path, note whether the error is logged, at what severity, whether it's re-thrown/re-raised or swallowed, and whether the caller has any way to distinguish a recoverable error from a fatal one. Identify inconsistencies — similar situations handled differently in different places — and for each one, note which behavior looks intentional versus which looks like it was just never standardized. Do not change any error-handling code yet. Produce a report grouped by inconsistency pattern (not by file), with a recommended standard for each pattern, and wait for me to confirm before applying any of it.
Tips
- Grouping the report by inconsistency pattern rather than by file makes it much easier to see the handful of real decisions buried in a long list of individual catch blocks
- Ask explicitly which behaviors look intentional — an audit that treats every inconsistency as a bug will flag legitimate special-casing along with actual drift
- Once you've picked which patterns to standardize, run the fix as its own separate pass rather than folding it into the audit itself
Still waiting on a reset? See what to do when you hit the limit, or check Codex / Claude time since last reset.
Back to the prompt library · Subscribe: all-products feed