error-handling

Error Handling (Deep)

Depth skill for pass 4 (errorHandling). Pair with cortexloop-expert-core and edge-case-and-state-analysis.

Go deep on failure semantics. Trace what happens when things go wrong — visibility, propagation, recovery, partial failure. Security exploit via error message → defer security; wrong business result → defer review.

Goal

Catch silent failures and misleading failure behavior — not every compact guard clause. A good finding names the hidden failure and who suffers.

Depth checklist

Swallowing & masking

• Empty catch {} or catch (e) { log(e) } then continue on critical path
• .catch(() => null) / Result ignored / floating promise
• Optional chaining short-circuit hiding undefined from missing upstream failure
• Default fallback values (|| [], ?? 0) that hide absent data or failed fetch

Propagation

• Error transformed to generic message losing actionable context for callers
• Re-throw without cause / wrapped exception losing stack
• Mixed sync/async: callback err not checked; event emitter error unhandled
• Go/Rust: _ = err / unwrap in non-test code

Critical vs non-critical paths

• Same swallow policy for payment write and analytics ping
• Background job failure invisible to operator
• User sees success UI while async step still failing

Retries & resilience

• Retry without max attempts, exponential backoff, or jitter
• Retry on non-idempotent operation → duplicate side effects
• Circuit breaker missing on cascading failure
• Timeout too long / missing → hung request blocks resources

Retry performance cost → defer performance. Frame here as wrong recovery semantics.

Partial failure & transactions

• Batch: item 3 fails — are items 1–2 committed? User informed?
• Saga/compensation missing after step 2 succeeds, step 3 fails
• File written then DB rollback → orphan artifact
• Dual write inconsistency (cache updated, DB not)

Observability

• Error logged without correlation id / request context
• Log level wrong (ERROR for expected validation; DEBUG for data loss)
• Metrics never incremented on failure class
• Alerting gap on silent degradation (fallback always used)