1 Defensive Programming and Debugging (Chapters 8 and 23 of Code Complete) Tori Bowman CSSE 375, Rose-Hulman September 21, 2007

What’s coming up?  What’s due  Defensive Programming and Debugging (this)  Project work 2

What’s due?  HW3 due 11:55 PM Monday  Please have read the following by Tuesday:     Come to class prepared to discuss your opinion on how open source software does or does not impact intellectual property. You will be expected to back up your opinion with examples/references from the above 3 articles. 3

4 Defensive Programming

5 What is Defensive Programming?  Like defensive driving  Main goal – protect yourself from bad data or other factors you cannot control  How can it be used in detailed design and implementation?

What to do with garbage?  “Garbage in, garbage out” (inappropriate for production code)  Check the values of all data from external sources  Check the values of all routine input parameters  Decide how to handle bad inputs 6

7 Defensive Programming Techniques  Assertions  Error handling  Code insertion for finding bad data  Note: These techniques can also be used elsewhere besides defensive programming

8 Assertions  Definition: code that’s used during development – usually a routine or macro – that allows a program to check itself as it runs  Assertions are intended to always be silent – only use for conditions that should never occur  Avoid putting executable code into assertions  Use to document/verify pre-/post-conditions

Error handling  Return a neutral value  Substitute the next valid data  Return previously valid data  Substitute closest “legal” value  Log a warning  Return an error code  Call an error-processing routine/object  Display an error message  Whatever is logical  Shutdown 9 **For errors you do expect to occur

10 Code insertion  Use this during development only Can be as simple as an output statement to a file or screen Advantage: independent of programming environment Preprocessing in C++ can help with this #define DEBUG. #if defined (DEBUG) // debugging code #endif

11 Defensive Programming and Production Code  Leave in code that Checks for important errors Helps the program crash gracefully  Remove code that Checks for trivial errors Hard crashes as a “signal” to testers  Log errors for technical support  Make error messages user-friendly

12 Defensive Programming Checklist  Pages of Code Complete  Sections General  Example: Protected from bad input data? Exceptions  Example: Did you avoid exceptions in constructors/destructors? Security Issues  Example: Do error messages avoid providing valuable info that can be used to break the system?

13 Debugging

Comic of the Day 14

15 Definition Debugging is the process of finding and fixing an error in code that was found through testing. *testing here is meant to include all forms

16 Benefits of Debugging  Debugging helps in: understanding the program understanding the types of errors you make (you can form a checklist to help find these errors earlier) in assessing readability and understandability of code

17 Debugging Process 1.Stabilize the error 2.Locate the source of an error 3.Fix the error 4.Test the fix 5.Look for similar errors 6. *Regression testing

18 Common Debugging Problems  Reading your own code can lead to you making assumptions about the code that you shouldn’t  Sometimes a fix is attempted without looking at the overall effect (regression testing helps here)  Sometimes a fix is attempted as a guess or without determining why the problem really occurred

19 Debugging Tools  GCC – must include debug options when compiling  Visual Studio 2005 Debugging Info  Note how debugging tools vary widely from application to application  However, debugging techniques do not change