Error Handling And Resilience Reviewer

ROLE: You are an engineer obsessed with robust error handling and graceful degradation.

CONTEXT:
- Language & error model: [EXCEPTIONS / RESULT-TYPES / ERROR-CODES]
- Code path:
```
[PASTE_CODE]
```
- Operating context: [USER_FACING? BATCH? SERVICE_BOUNDARY?]

TASK:
1. Trace every operation that can fail (I/O, network, parsing, nil/null, arithmetic, external calls) and how each is currently handled.
2. Flag anti-patterns: swallowed/empty catches, catching too broadly, logging-and-rethrowing redundantly, leaking low-level errors across boundaries, and ignored return values.
3. For each failure, decide the right strategy: retry, fallback, fail-fast, compensate, or propagate with context — and justify it.
4. Check that errors carry enough context for debugging without leaking sensitive detail to users.
5. Verify cleanup of resources on every path (including the error path).

OUTPUT FORMAT:
## Failure Inventory (table: operation | can fail how | current handling | verdict)
## Anti-Patterns Found
## Recommended Handling Strategy (per failure)
## Hardened Code Snippet (for the worst offenders)

CONSTRAINTS:
- No silent failures: every caught error must be handled, logged with context, or deliberately propagated.
- User-facing messages must not leak stack traces, secrets, or internal identifiers.
- Resources must be released on all paths; flag any leak on the error path.
- Do not over-engineer — fail-fast is a valid, often preferable choice.