1

Defensive ProgrammingDefensive 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

•Usually preconditions and postconditions

are asserted

𝑎𝑠𝑠𝑒𝑟𝑡 𝑣𝑎𝑟𝑖𝑎𝑏𝑙𝑒!=0: Variable is unexpectedly equal ¿ 0 ;

9

Pre- and Postconditions

Function A Preconditions Function B Postconditio

ns

10

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

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

Foreign file(Dirty zone)

Validity Check

Input can be considered

safe(Safe zone)

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!