1 / 19

Defensive Programming and Debugging (Chapters 8 and 23 of Code Complete )

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. What’s due?. HW3 due 11:55 PM Monday

courtneyl
Download Presentation

Defensive Programming and Debugging (Chapters 8 and 23 of Code Complete )

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. What’s due? • HW3 due 11:55 PM Monday • Please have read the following by Tuesday: • http://www.abanet.org/intelprop/opensource.html • http://www.monthlyreview.org/0103perelman.htm • http://www.groklaw.net/article.php?story=20031231092027900 • 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.

  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?

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

  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

  9. Error handling **For errors you do expect to occur • 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

  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 andProduction 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 211-212 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

  14. Comic of the Day

  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 http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html • Visual Studio 2005 Debugging Info http://msdn2.microsoft.com/en-us/library/sc65sadd.aspx • Note how debugging tools vary widely from application to application • However, debugging techniques do not change

More Related