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:

Check	Why
No executable code in assertions	Assertions are compiled out of production builds; the code vanishes with them
No empty catch blocks	Silently swallows bugs that cascade into harder failures downstream
External input validated at entry	Unvalidated input is security vulnerabilities and data corruption
Assertions for bugs only	Anticipated runtime errors need handling, not assertions (which are disabled in production)

Shared thresholds and the information-hiding rationale: Read(${CLAUDE_PLUGIN_ROOT}/references/cc-foundations.md).

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.