Defensive Programming
Defensive Programming
Nikolaus Embgen
Topics
1. Motivation 2. The concept
3. What can we do?
4. How to use this?
5. What else can we do?
6. The conclusion
Motivation
•Protection from invalid input
•Checking for buggy code
•Error prevention
•Crash prevention
The concept
Derived from defensive driving:
•Don‘t trust people
•Don‘t assume ability
•„Keep your guard up“
The concept
Conveyed to computer science:
•Don‘t trust foreign sources
•Don‘t assume ability of flawless code
What can we do?
What can we do?
•Assert conditions
•Handle errors
•Build something correct
•Build something robust
Assertions
•Primarily for preventable errors
•Checkpoints inside the program
•Usually preconditions and postconditions are asserted
�������������� !=0: Variable is unexpectedly equal ¿ 0 ;
Pre- and Postconditions
Function A Precondition
s Function B Postconditio
ns
Error handling
•Primarily for unpreventable errors
•Designed to handle errors gracefully
•Don‘t make errors easily dismissable for yourself
E.g. missing files, corrupted files, invalid input characters
Assertions vs Error Handling
•Assertions make your program correct
•Error handling makes it robust
How do we use this?
Correctness
•The program is optimized to weed out wrong outputs
•Wrong output is considered a critical failure
Robustness
•Makes the program very stable
•Keeps user annoyance to a minimum
•Wrong output is not very severe
Correctness vs. Robustness
•Correctness: Safety critical applications need to be correct (e.g X-Ray)
•Robustness: Reliability critical applications (e.g. Mediaplayer)
What else can we do?
Containment
•Partition your code into zones
•Build validation doors
•Create „dirty“ and „safe“ zones
Containment
Foreign file
(Dirty zone) Validity Check
Input can be considered
safe
(Safe zone)
Exceptions
•Function „throws up its hands“
•Use where necessary, not everywhere
•Don‘t call exceptions in Constructors and Destructors
Conclusion
•Assert your mistakes and handle foreign mistakes
•Choose correctness OR robustness
•Also keep security in mind
What to watch out for
•Don‘t check every thing: fat and slow
•Added complexity (especially with exceptions)
•Defensive code is not immune to errors
