Error Handling Adequacy Review Prompt

This prompt is designed for developers and tech leads who need to audit a pull request diff for error handling gaps. It targets three high-risk patterns: missing error handling on operations that can fail, exceptions that are caught and silently swallowed, and overly broad catch blocks that mask specific failure modes. Use this prompt in CI/CD pipelines as a pre-merge gate, during manual code review to catch what human eyes often skip, or as part of a security and reliability review checklist. The prompt assumes you have a unified diff as input and that the code is in a language with structured exception handling.

The ideal input is a git diff output or a unified diff file that captures the exact changes under review. The prompt works best when the diff is scoped to a single logical change, as large, multi-concern diffs can dilute the model's focus and produce noisier findings. You should configure the [RISK_LEVEL] placeholder to match your team's tolerance—setting it to strict will flag more potential issues, including unhandled promises in async code, while relaxed will focus only on the most obvious gaps. The [CONSTRAINTS] placeholder allows you to inject language-specific rules, such as "flag any function that returns a Result type without a caller check" or "ignore error handling inside test files."

This prompt does not replace human judgment for critical paths, nor does it verify that the suggested remediation patterns are semantically correct for the specific codebase. It may produce false positives in code that uses non-standard error propagation patterns or frameworks with centralized exception handlers. Always require human approval for findings marked critical or high severity before merging. Do not use this prompt as the sole gate for security-sensitive or safety-critical code paths—pair it with static analysis tools and manual review for those contexts.

The following prompt template is designed to be pasted directly into your AI system or prompt management platform. It instructs the model to act as a senior code reviewer focused exclusively on error handling adequacy. The template uses square-bracket placeholders that you must replace with real values before execution. Do not leave any placeholder unresolved in production; the model will treat them as literal instructions and produce unreliable output.

textCopy
You are a senior software engineer conducting a focused code review on error handling. Your only task is to identify missing, inadequate, or overly broad error handling in the provided code diff.

## INPUT
Code Diff:

[CODE_DIFF]

codeCopy

Language: [LANGUAGE]
Context (optional): [CONTEXT]

## CONSTRAINTS
- Only report findings related to error handling. Do not comment on naming, style, performance, or logic unless it directly impacts error handling correctness.
- For each finding, reference the specific file path and line range from the diff.
- If no error handling issues are found, return an empty findings list. Do not fabricate issues.
- Do not suggest changes that would alter the intended business logic.
- If the diff contains test files, review them for missing error-path test coverage.

## OUTPUT_SCHEMA
Return a valid JSON object with this exact structure:
{
  "summary": "A one-sentence summary of the overall error handling posture of this diff.",
  "findings": [
    {
      "severity": "critical|high|medium|low",
      "category": "missing_handler|swallowed_exception|overly_broad_catch|empty_catch|missing_log_context|unhandled_promise|missing_rollback|missing_user_feedback|missing_test_coverage",
      "file": "path/to/file.ext",
      "line_range": "L12-L18",
      "description": "What is wrong and why it matters.",
      "suggested_fix": "A concrete code example showing the recommended pattern.",
      "current_code_snippet": "The problematic code from the diff."
    }
  ]
}

## RISK_LEVEL
This review is for [RISK_LEVEL] risk code. Adjust severity thresholds accordingly:
- low: Only flag missing handlers that could cause data loss or crashes.
- medium: Flag swallowed exceptions, empty catch blocks, and missing log context.
- high: Flag everything including overly broad catch blocks, missing rollback logic, and missing user-facing error messages.

## EXAMPLES
Example finding for a swallowed exception:
{
  "severity": "high",
  "category": "swallowed_exception",
  "file": "src/payment/processor.ts",
  "line_range": "L45-L48",
  "description": "Payment processing exception is caught and silently ignored. A failed charge will appear to succeed, causing revenue loss and customer confusion.",
  "suggested_fix": "try { await chargeCustomer(); } catch (error) { logger.error('Charge failed', { orderId, error }); throw new PaymentFailedError('Unable to process payment', { cause: error }); }",
  "current_code_snippet": "try { await chargeCustomer(); } catch (e) {}"
}

To adapt this template, replace the placeholders with real data. [CODE_DIFF] should contain the full unified diff output. [LANGUAGE] helps the model apply language-idiomatic error handling patterns (e.g., try/catch for JavaScript, Result<T, E> for Rust). [CONTEXT] is optional but valuable for providing module purpose, known failure modes, or team conventions. [RISK_LEVEL] directly controls the strictness of the review; use high for payment, auth, or data mutation code, and low for internal tooling or non-critical paths. After pasting, validate that the model output conforms to the OUTPUT_SCHEMA before ingesting it into your review tool. If the output fails schema validation, retry with a stricter temperature setting or add a repair step using the schema error message as feedback.

This prompt is designed to be called programmatically as part of a pull request review pipeline. The primary input is a unified diff, typically obtained from a version control system like Git. The application layer should extract the diff from the PR event, inject it into the [DIFF] placeholder, and handle the structured JSON output. Because the analysis is static and non-interactive, this prompt is well-suited for a single-turn, zero-temperature call to a capable model like GPT-4o or Claude 3.5 Sonnet. The model should be instructed to produce JSON only, without markdown fences, to simplify parsing.

A robust harness must validate the model's output against a strict JSON schema before any findings are posted as review comments. The schema should enforce that each finding object contains a line_number (integer), severity (enum of 'critical', 'high', 'medium', 'low'), category (string), description (string), and suggestion (string). If the output fails schema validation, implement a retry loop with a maximum of two attempts. On a retry, feed the raw output and the validation error message back to the model with a correction instruction. If validation fails after retries, the harness should log the failure and alert the development team rather than posting a partial or malformed review.

For high-risk repositories, integrate a human approval gate for all 'critical' severity findings. The harness should post lower-severity findings as standard inline review comments but flag critical findings in a separate, blocked state that requires a tech lead to acknowledge before the PR can be merged. Log every prompt call with a unique trace ID, capturing the input diff hash, the raw model output, the validation result, and the final posted findings. This audit trail is essential for debugging prompt drift, evaluating false positive rates, and iterating on the prompt template itself. Avoid wiring this prompt to automatically reject or close a PR; its role is to inform human decision-making, not to replace it.