ryanthedev/code-foundations/cc-defensive-programming

cc-defensive-programming

Defensive code keeps small failures from compounding into silent, hard-to-diagnose ones. These four checks catch the violations that corrupt data and hide bugs rather than crashing loudly — each is almost always required; exceptions need explicit justification:

Two rules that override the textbook

• "Internal team API" is still external. Any data crossing a network or process boundary is external input — validate it, even from a service your own team owns.
• A barricade reduces redundant validation; it does not replace defense-in-depth. Inside the barricade you may assume data is validated — except for security-critical paths (auth, crypto, PII), where you validate again. Barricade validation has bugs too.

External input = any data not provably controlled by the current code path: user input, files, network/API/DB responses, environment variables, and data from any other service.

When NOT to apply

• Pure functions without side effects (but still validate inputs at system boundaries).
• Prototype/spike code, time-boxed before committing to an error strategy.
• Test code — test doubles intentionally violate production patterns.
• Performance-critical inner loops where assertion overhead is profiled at >5%.

Security-critical code (authentication, authorization, cryptographic operations, PII handling) is never exempt, regardless of the above. When in doubt, validate.

Modes

CHECKER

Execute the defensive-programming, assertion, and exception checklists against the code: Read(${CLAUDE_SKILL_DIR}/checklists.md). VIOLATION = missing validation, empty catch, side-effecting assertion; WARNING = inconsistent handling, missing docs. CHECKER output: the ID'd checklist is the item set (the tables in this SKILL.md explain the items, they are not counted twice). Report each VIOLATION and WARNING as | Item | Status | Evidence | Location |; do not list passing or non-applicable items — close with one line N items checked, M pass, K n/a.

APPLIER

Produce assertion placement, error-handling strategy, barricade architecture, and validation implementations. Search the codebase for the existing error-handling pattern (exception vs return code vs Result type, custom exception classes, logging conventions) and follow it — consistency in error handling is what makes failures debuggable.

Assertion vs error handling

When a condition is genuinely unclear ("is this a bug or expected?"), clarify requirements with a domain expert rather than guessing.

Correctness vs robustness

• Correctness — never return an inaccurate result; shut down rather than produce a wrong answer (safety-critical, financial, data pipelines).
• Robustness — keep operating even if results are sometimes inaccurate (consumer apps, internal tools).

Barricade design

1. Identify external interfaces (user input, files, network, APIs, inter-service calls).
2. Place validation at the barricade boundary — all external data checked here.
3. Inside the barricade, use assertions for internal bugs (data assumed validated).
4. Strategy: external boundary = error handling; internal = assertions.

Class-level barricade: public methods validate and sanitize; private methods within that class may assume safe data.

Error-handling strategy options

Choose one and apply it consistently — error handling is an architectural decision.

Modern error propagation

Synchronous exception propagation assumes a synchronous call stack; these patterns need explicit handling:

• async/await — an unhandled rejection crashes Node; wrap awaited calls and re-throw domain-level exceptions.
• Callbacks — errors don't propagate; use the error-first callback(error, result) pattern or wrap in promises.
• `Promise.all` — first rejection loses other results; use allSettled and decide fail-entirely vs partial.
• Event handlers / React — synchronous throws are silently swallowed; log explicitly and use error boundaries for render errors.

Offensive programming (development builds)

Make errors loud during development so they're found early; make them unobtrusive with graceful recovery in production. Techniques: make asserts abort, fill allocated memory and freed objects with junk, fail hard on default/else clauses, email error logs to yourself.