defensive programming

  • defensive
    • assume everything you don't control (hardware, 3rd party libraries, user inputs, network protocols) will violate your assumptions and misbehave from time to time.
    • find ways to handle these errors gracefully w/o crashing the whole system (try/catch).
  • offensive
    • within your own internal code, you can define invariants (things that must always be true if your internal code is correct).
    • if a invariant is violated, it means someone introduced a bug & now the system is in a state you never designed for, so you should crash the program (assert).
    • in other words, we should fail loudly when we invariants are violated within the code we control.