Defensive Programming for Robust Code
undefined
Defensive Programming
Defensive Programming
1
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
2
Motivation
•
Protection from invalid input
•
Checking for buggy code
•
Error prevention
•
Crash prevention
3
The concept
Derived from defensive driving:
•
Don‘t trust people
•
Don‘t assume ability
•
„Keep your guard up“
4
The concept
Conveyed to computer science:
•
Don‘t trust
foreign sources
•
Don‘t assume ability
of flawless code
5
What can we do?
6
What can we do?
•
Assert conditions
•
Handle errors
•
Build something correct
•
Build something robust
7
Assertions
•
Primarily for preventable errors
•
Checkpoints inside the program
•
Usually preconditions and postconditions
are asserted
8
Pre- and Postconditions
9
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
Assertions vs Error Handling
•
Assertions make your program correct
•
Error handling makes it robust
11
How do we use this?
12
Correctness
•
The program is optimized to weed out
wrong outputs
•
Wrong output is considered a critical
failure
13
Robustness
•
Makes the program very stable
•
Keeps user annoyance to a minimum
•
Wrong output is not very severe
14
Correctness vs. Robustness
•
Correctness: Safety critical applications
need to be correct (e.g X-Ray)
•
Robustness: Reliability critical applications
(e.g. Mediaplayer)
15
What else can we do?
16
Containment
•
Partition your code into zones
•
Build validation doors
•
Create „dirty“ and „safe“ zones
17
Containment
18
Exceptions
•
Function „throws up its hands“
•
Use where necessary, not everywhere
•
Don‘t call exceptions in Constructors and
Destructors
19
Conclusion
•
Assert your mistakes and handle foreign
mistakes
•
Choose correctness OR robustness
•
Also keep security in mind
20
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
Let defensive programming make
your life easier not harder.
22
Thank you for your
attention!
23
Defensive programming, as explained by Nikolaus Embgen, is a proactive approach to writing code that focuses on error prevention, input validation, and robustness. It emphasizes not trusting external sources and assuming potential flaws in the code. By using techniques such as assertions, error handling, and pre-/postconditions, developers can build more reliable and resilient software systems. The concept is derived from defensive driving principles and aims to create programs that are correct and robust. Ultimately, defensive programming helps in identifying and addressing issues early in the development process, leading to more stable and secure applications.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
1 Defensive Programming Defensive Programming 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
3 Motivation Protection from invalid input Checking for buggy code Error prevention Crash prevention
4 The concept Derived from defensive driving: Don t trust people Don t assume ability Keep your guard up
5 The concept Conveyed to computer science: Don t trust foreign sources Don t assume ability of flawless code
6 What can we do?
7 What can we do? Assert conditions Handle errors Build something correct Build something robust
8 Assertions Primarily for preventable errors Checkpoints inside the program ?????? ???????? ! = 0:"Variable is unexpectedly equal to 0"; Usually preconditions and postconditions are asserted
9 Pre- and Postconditions Function A Preconditions Function B Postconditions
10 Error handling Primarily for unpreventable errors E.g. missing files, corrupted files, invalid input characters Designed to handle errors gracefully Don t make errors easily dismissable for yourself
11 Assertions vs Error Handling Assertions make your program correct Error handling makes it robust
12 How do we use this?
13 Correctness The program is optimized to weed out wrong outputs Wrong output is considered a critical failure
14 Robustness Makes the program very stable Keeps user annoyance to a minimum Wrong output is not very severe
15 Correctness vs. Robustness Correctness: Safety critical applications need to be correct (e.g X-Ray) Robustness: Reliability critical applications (e.g. Mediaplayer)
16 What else can we do?
17 Containment Partition your code into zones Build validation doors Create dirty and safe zones
18 Containment Input can be considered safe (Safe zone) Foreign file (Dirty zone) Validity Check
19 Exceptions Function throws up its hands Use where necessary, not everywhere Don t call exceptions in Constructors and Destructors
20 Conclusion Assert your mistakes and handle foreign mistakes Choose correctness OR robustness Also keep security in mind
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
22 Let defensive programming make your life easier not harder.
23 Thank you for your attention!
