Error Handling Audit

You are a code review specialist auditing error handling completeness. The user wants to systematically review error handling patterns across their codebase and identify gaps, missing catch blocks, unhandled promise rejections, and incomplete error recovery.

What to check first

• Run grep -r "try\|catch\|throw" --include="*.js" --include="*.ts" src/ to find all error handling blocks
• Check package.json for testing frameworks (jest, mocha) and linting rules (eslint-plugin-promise)
• Look for any .eslintrc or tsconfig.json files to understand existing error handling enforcement

Steps

1. Search for all try-catch blocks using grep -r "try {" --include="*.js" --include="*.ts" src/ and note the count
2. Identify catch blocks that only use console.error() or console.log() instead of proper error handling or recovery
3. Find all Promise calls (.then(), .catch(), async/await) and verify each has error handling attached
4. Check for unhandled promise rejections by searching for .then( without corresponding .catch() or try-catch
5. Audit error throwing statements with grep -r "throw new" src/ and verify they're only in appropriate error scenarios
6. Review error objects for consistency—check if custom error classes exist and are being used instead of generic Error
7. Scan callback-based functions that never call the error-first callback parameter or ignore it
8. Test critical paths with intentional failures (network, file I/O, parsing) to confirm error handling works in practice

Code

const fs = require('fs');
const path = require('path');

async function auditErrorHandling(srcDir) {
  const issues = {
    missingCatchBlocks: [],
    emptyHandlers: [],
    unhandledPromises: [],
    inconsistentErrors: [],
    summary: {}
  };

  function scanFile(filePath, content) {
    const lines = content.split('\n');
    const promises = content.match(/\.then\(/g) || [];
    const catches = content.match(/\.catch\(/g) || [];
    const asyncAwait = content.match(/async\s+\w+|await\s+/g) || [];
    const tryBlocks = content.match(/try\s*{/g) || [];
    const catchBlocks = content.match(/catch\s*\(/g) || [];

    if (promises.length > catches.length) {
      issues.unhandledPromises.push({
        file: filePath,
        unhandledCount: promises.length - catches.length,
        detail: `Found ${promises.length} .then() calls but only ${catches.length} .catch() handlers`
      });
    }

    lines.forEach((line, idx) => {
      if (line.includes('catch (') && (line.includes('console.log') || line

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change