Standalone Mode

If invoked directly (not via the orchestrator), you must first:

Read
```
../codeprobe/shared-preamble.md
```
for the output contract, execution modes, and constraints.
Load applicable reference files from
```
../codeprobe/references/
```
based on the project's tech stack.
Default to
```
full
```
mode unless the user specifies otherwise.

Error Handling & Resilience Checker

This sub-skill detects error handling and resilience issues across these categories:

Swallowed Exceptions — Empty catch blocks, catch-and-log-only without rethrow/handle
Missing Error Handling — External API calls without try/catch, unhandled promise rejections
Error Information — Generic error messages, leaking internals, missing structured responses
Retry & Circuit Breaker — No timeout on external calls, no retry for transient failures
Validation — Missing input validation, implicit null assumptions, type coercion bugs
Transaction Safety — Multi-step DB operations without transactions, missing rollback
Logging — No logging on critical paths, missing correlation IDs

Sensitive data in logs — covered by
```
codeprobe-security
```
(
```
SEC
```
prefix). This sub-skill flags missing logging and structural issues like no correlation IDs, not data leakage.
Test files — test exception handling follows different patterns and is expected to be simpler.
Framework-generated exception handlers (e.g., Laravel's
```
Handler.php
```
, Next.js error boundaries that are intentionally minimal) — these are scaffolded defaults, not developer oversights.
CLI scripts with intentionally simple error handling (print + exit) — command-line tools often use a valid pattern of printing an error and exiting with a non-zero code.
Catch blocks that deliberately swallow specific known-harmless exceptions with a comment explaining why — if the developer documented the rationale, respect the decision.
Issues that are primarily security vulnerabilities (e.g., authentication bypasses, injection, data exposure) even if they also have error handling implications — these are covered by
```
codeprobe-security
```
. If both sub-skills flag the same location, the orchestrator will deduplicate and keep the security finding as primary.

ID Prefix	What to Detect	How to Detect	Severity
`ERR`	Empty catch blocks	Search for `catch` blocks with empty body, only `pass` , only `// ignored` , or only a comment. In JS/TS: `catch (e) {}` . In PHP: `catch (\Exception $e) {}` . In Python: `except: pass` or `except Exception: pass` .	Major
`ERR`	Catch-log-only without handling	Find catch blocks that only contain a log/print statement but don't rethrow, return an error, or take any recovery action. The exception is swallowed after logging.	Minor
`ERR`	Overly broad exception catching	`catch (\Exception $e)` , `catch (Exception e)` , bare `except:` in Python, `catch (e)` catching all errors. Flag when a more specific exception type should be caught.	Major

ID Prefix	What to Detect	How to Detect	Severity
`ERR`	External API calls without try/catch	Search for HTTP client calls (Guzzle, axios, fetch, requests, HttpClient), payment SDK calls (Stripe, PayPal), AWS SDK calls, and other external service integrations. Flag when these calls are NOT wrapped in try/catch or .catch().	Major
`ERR`	Unhandled promise rejections	Search for async functions or promise chains without `.catch()` or surrounding try/catch. Look for floating promises (async call without await). In Node.js, check for missing `unhandledRejection` handler.	Major
`ERR`	File I/O without error handling	`file_get_contents` , `fopen` , `fs.readFile` , `open()` (Python) without try/catch for IOError/FileNotFoundError.	Minor

ID Prefix	What to Detect	How to Detect	Severity
`ERR`	Generic error messages	API responses returning only "Something went wrong", "Internal server error", or similar without error codes or actionable detail for the client.	Minor
`ERR`	Leaking internal errors to API consumers	Exception messages, stack traces, SQL errors, or file paths exposed in API JSON/HTML responses. Check error handling middleware configuration.	Major
`ERR`	Missing structured error responses	API endpoints returning errors without consistent structure (no error code field, no message field, inconsistent formats across endpoints).	Minor

ID Prefix	What to Detect	How to Detect	Severity
`ERR`	External service calls without timeout	HTTP client calls without timeout configuration. Guzzle without `timeout` option, axios without `timeout` , requests without `timeout` param, fetch without AbortController.	Major
`ERR`	No retry for transient failures	External API calls that could fail transiently (HTTP 429, 503, network errors) with no retry mechanism.	Minor
`ERR`	No circuit breaker for cascading failures	Service-to-service calls in microservice architectures with no circuit breaker or fallback pattern.	Suggestion

ID Prefix	What to Detect	How to Detect	Severity
`ERR`	Missing input validation before processing	Functions that accept external input (request params, file contents, API payloads) and use them directly without validation.	Major
`ERR`	Implicit null assumptions	Accessing properties or calling methods on values that could be null/undefined without null checks. Chaining `.` access on possibly-null return values.	Minor
`ERR`	Type coercion bugs	PHP `==` instead of `===` for security-sensitive comparisons. JS `==` instead of `===` . Implicit type conversions that could produce unexpected results.	Minor

ID Prefix	What to Detect	How to Detect	Severity
`ERR`	Multi-step DB ops without transactions	Multiple `INSERT` / `UPDATE` / `DELETE` queries in sequence (same method) without `DB::transaction()` , `atomic()` , `BEGIN` / `COMMIT` , or equivalent. If any step fails, data is left in an inconsistent state.	Critical
`ERR`	Transaction without proper rollback	Transaction blocks that catch exceptions but don't rollback, or that have code after the transaction that assumes success without checking.	Major

ID Prefix	What to Detect	How to Detect	Severity
`ERR`	No logging on critical failure paths	Catch blocks in critical business logic (payment, auth, order processing) that don't include any logging. Failures happen silently.	Major
`ERR`	Missing correlation/request IDs	Log statements in request-handling code without correlation ID, request ID, or trace ID. Makes debugging distributed issues impossible.	Minor

All findings use the

ERR-

prefix, numbered sequentially:

ERR-001

ERR-002

, etc.

"Wrap the Stripe API call in
```
PaymentService@charge
```
(line 55) in a try/catch for
```
\Stripe\Exception\ApiErrorException
```
. Log the error with context (
```
$orderId
```
,
```
$amount
```
) and throw a domain-specific
```
PaymentFailedException
```
with a user-friendly message."
"Add
```
DB::transaction()
```
around the order creation flow in
```
OrderService@create
```
(lines 40-65) which currently creates an Order, OrderItems, and Payment record in three separate queries. If any step fails, all should roll back."
"Replace the empty catch block at
```
app/Services/NotificationService.php:88
```
with proper error handling: log the exception with notification context, then decide whether to rethrow (critical notification) or swallow with a metric (non-critical)."
"Add timeout and retry configuration to the HTTP client call at
```
ExternalApiClient.php:30
```
. Use
```
->timeout(10)->retry(3, 100)
```
for the Guzzle request to handle transient network failures."