1. Defensive Programming 1 Nikolaus Embgen

2. 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 2

3. Motivation Protection from invalid input Checking for buggy code Error prevention Crash prevention 3

4. The concept Derived from defensive driving: Don‘t trust people Don‘t assume ability „Keep your guard up“ 4

5. The concept Conveyed to computer science: Don‘t trust foreign sources Don‘t assume ability of flawless code 5

6. What can we do? 6

7. Assert conditions Handle errors Build something correct Build something robust 7

8. Assertions Primarily for preventable errors Checkpoints inside the program Usually preconditions and postconditions are asserted 8

9. Pre- and Postconditions Function APreconditionsFunction BPostconditions 9

10. Error handling Primarily for unpreventable errors Designed to handle errors gracefully Don‘t make errors easily dismissable for yourself 10 E.g. missing files, corrupted files, invalid input characters

11. Assertions vs Error Handling Assertions make your program correct Error handling makes it robust 11

12. How do we use this? 12

13. Correctness The program is optimized to weed out wrong outputs Wrong output is considered a critical failure 13

14. Robustness Makes the program very stable Keeps user annoyance to a minimum Wrong output is not very severe 14

15. Correctness vs. Robustness Correctness: Safety critical applications need to be correct (e.g X-Ray) Robustness: Reliability critical applications (e.g. Mediaplayer) 15

16. What else can we do? 16

17. Containment Partition your code into zones Build validation doors Create „dirty“ and „safe“ zones 17

18. Containment Foreign file (Dirty zone) Validity Check Input can be considered safe (Safe zone) 18

19. Exceptions Function „throws up its hands“ Use where necessary, not everywhere Don‘t call exceptions in Constructors and Destructors 19

20. Conclusion Assert your mistakes and handle foreign mistakes Choose correctness OR robustness Also keep security in mind 20

21. 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 21

22. Let defensive programming make your life easier not harder. 22

23. Thank you for your attention! 23