Defensive Programming Defensive Programming 1
Description: Defensive Programming Defensive Programming 1 Nikolaus Embgen Topics Motivation The concept What can we do? How to use this? What else can we do? The conclusion 2 Motivation Protection from invalid input Checking for buggy code Error
Related Topics
Download Presentation
"Defensive Programming Defensive Programming 1" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
slide1. Defensive Programming Defensive Programming 1 Nikolaus Embgen<br>
slide2. Topics Motivation
The concept
What can we do?
How to use this?
What else can we do?
The conclusion 2<br>
slide3. Motivation Protection from invalid input
Checking for buggy code
Error prevention
Crash prevention 3<br>
slide4. The concept Derived from defensive driving:
Don‘t trust people
Don‘t assume ability
„Keep your guard up“ 4<br>
slide5. The concept Conveyed to computer science:
Don‘t trust foreign sources
Don‘t assume ability of flawless code 5<br>
slide6. What can we do? 6<br>
slide7. What can we do? Assert conditions
Handle errors
Build something correct
Build something robust 7<br>
slide8. Assertions Primarily for preventable errors
Checkpoints inside the program
Usually preconditions and postconditions are asserted 8<br>
slide9. Pre- and Postconditions 9<br>
slide10. 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<br>
slide11. Assertions vs Error Handling Assertions make your program correct
Error handling makes it robust 11<br>
slide12. How do we use this? 12<br>
slide13. Correctness The program is optimized to weed out wrong outputs
Wrong output is considered a critical failure 13<br>
slide14. Robustness Makes the program very stable
Keeps user annoyance to a minimum
Wrong output is not very severe 14<br>
slide15. Correctness vs. Robustness Correctness: Safety critical applications need to be correct (e.g X-Ray)
Robustness: Reliability critical applications (e.g. Mediaplayer) 15<br>
slide16. What else can we do? 16<br>
slide17. Containment Partition your code into zones
Build validation doors
Create „dirty“ and „safe“ zones 17<br>
slide18. Containment 18<br>
slide19. Exceptions Function „throws up its hands“
Use where necessary, not everywhere
Don‘t call exceptions in Constructors and Destructors 19<br>
slide20. Conclusion Assert your mistakes and handle foreign mistakes
Choose correctness OR robustness
Also keep security in mind 20<br>
slide21. 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<br>
slide22. Let defensive programming make your life easier not harder. 22<br>
slide23. Thank you for your attention! 23<br>
slide2. Topics Motivation
The concept
What can we do?
How to use this?
What else can we do?
The conclusion 2<br>
slide3. Motivation Protection from invalid input
Checking for buggy code
Error prevention
Crash prevention 3<br>
slide4. The concept Derived from defensive driving:
Don‘t trust people
Don‘t assume ability
„Keep your guard up“ 4<br>
slide5. The concept Conveyed to computer science:
Don‘t trust foreign sources
Don‘t assume ability of flawless code 5<br>
slide6. What can we do? 6<br>
slide7. What can we do? Assert conditions
Handle errors
Build something correct
Build something robust 7<br>
slide8. Assertions Primarily for preventable errors
Checkpoints inside the program
Usually preconditions and postconditions are asserted 8<br>
slide9. Pre- and Postconditions 9<br>
slide10. 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<br>
slide11. Assertions vs Error Handling Assertions make your program correct
Error handling makes it robust 11<br>
slide12. How do we use this? 12<br>
slide13. Correctness The program is optimized to weed out wrong outputs
Wrong output is considered a critical failure 13<br>
slide14. Robustness Makes the program very stable
Keeps user annoyance to a minimum
Wrong output is not very severe 14<br>
slide15. Correctness vs. Robustness Correctness: Safety critical applications need to be correct (e.g X-Ray)
Robustness: Reliability critical applications (e.g. Mediaplayer) 15<br>
slide16. What else can we do? 16<br>
slide17. Containment Partition your code into zones
Build validation doors
Create „dirty“ and „safe“ zones 17<br>
slide18. Containment 18<br>
slide19. Exceptions Function „throws up its hands“
Use where necessary, not everywhere
Don‘t call exceptions in Constructors and Destructors 19<br>
slide20. Conclusion Assert your mistakes and handle foreign mistakes
Choose correctness OR robustness
Also keep security in mind 20<br>
slide21. 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<br>
slide22. Let defensive programming make your life easier not harder. 22<br>
slide23. Thank you for your attention! 23<br>