Defencive programming
0 likes952 views
The document discusses techniques for defensive programming, including checking for invalid inputs, using assertions to validate assumptions, handling errors gracefully, and using exceptions to pass errors to calling code. It recommends barricading programs to contain damage from errors, using assertions inside barricades and error handling outside, and determining what defensive checks to leave in production code based on importance and impact.
Defencive programming
- 1. Defensive Programming Code Complete Author : Steven C. McConnell. Prof. Asha N 1
- 2. Defensive Programming You take responsibility for protecting yourself even when it might be the others fault. Eg: if a routine is passed bad data it won’t be hurt, even if the bad data is another routine’s fault Prof. Asha N 2
- 3. Protecting Your Program From Invalid Inputs “Garbage in, garbage out.” A good program uses “garbage in, nothing out”; “garbage in, error message out”; or “no garbage allowed in” instead. Prof. Asha N 3
- 4. Contd…. three general ways to handle garbage in 1. 2. 3. Check the values of all data from external sources Check the values of all routine input parameters Decide how to handle bad inputs Prof. Asha N 4
- 5. Assertions An assertion is code - usually a routine or macro. an assertion is True - means everything is operating as expected. False - means it has detected an unexpected error in the code. An assertion takes two arguments: 1. a Boolean expression that describes the assumption that’s supposed to be true 2. a message to display if it isn’t. Prof. Asha N 5
- 6. Contd… assert denominator != 0 : "denominator is unexpectedly equal to 0."; denominator != 0, is a boolean expression that evaluates to True or False. The second argument is a message to print if the first argument is False—that is, if the assertion is false. C++ Example of an Assertion Macro #define ASSERT( condition, message ) { if ( !(condition) ) { fprintf( stderr, "Assertion %s failed: %sn", #condition, message ); exit( EXIT_FAILURE ); } } Prof. Asha N 6
- 7. Guidelines for Using Assertions Use error handling code for conditions you expect to occur; use assertions for conditions that should never occur Avoid putting executable code in assertions – Visual Basic Example of a Dangerous Use of an Assertion Debug.Assert( PerformAction() ) ' Couldn't perform action – Visual Basic Example of a Safe Use of an Assertion actionPerformed = PerformAction() Debug.Assert( actionPerformed ) ' Couldn't perform action Use assertions to document preconditions and postconditions For highly robust code, assert, and then handle the error anyway Prof. Asha N 7
- 8. Error Handling Techniques Return a neutral value Substitute the next piece of valid data Return the same answer as the previous time Substitute the closest legal value Log a warning message to a file Return an error code Call an error processing routine/object Display an error message wherever the error is encountered Handle the error in whatever way works best locally Shutdown Prof. Asha N 8
- 9. Exceptions Exceptions are a code can pass along errors or exceptional events to the code that called it. Code that has no sense of the context of an error can return control to other parts of the system that might have a better ability to interpret the error and do something useful about it. Prof. Asha N 9
- 10. Exceptions Benefits of exceptions and avoiding the difficulties often associated with them. Use exceptions to notify other parts of the program about errors that should not be ignored Throw an exception only for conditions that are truly exceptional Don’t use an exception to pass the buck Avoid throwing exceptions in constructors and destructors unless you catch them in the same place Throw exceptions at the right level of abstraction Include all information that led to the exception in the exception message Avoid empty catch blocks Know the exceptions your library code throws Consider building a centralized exception reporter Prof. Asha N 10
- 11. Contd…. Bad Java Example of a Class That Throws an Exception at an Inconsistent Level of Abstraction class Employee { ... public TaxId getTaxId() EOFException { ... } ... } Good Java Example of a Class That Throws an Exception at a Consistent Level of Abstraction class Employee { ... public TaxId getTaxId() throws EmployeeDataNotAvailable { ... } ... } Prof. Asha N 11
- 12. Barricade Your Program to Contain the Damage Caused by Errors Barricades used to be called “firewalls,” but the term “firewall” now commonly refers to port blocking. Check data crossing the boundaries of a safe area for validity and respond sensibly if the data isn’t valid Prof. Asha N 12
- 13. Relationship between Barricades and Assertions Routines that are outside the barricade should use error handling because it isn’t safe to make any assumptions about the data. Routines inside the barricade should use assertions, because the data passed to them is supposed to be sanitized before it’s passed across the barricade. Prof. Asha N 13
- 14. Debugging Aids Introduce Debugging Aids Early Use Offensive Programming Use version control and build tools like make Use a built-in preprocessor Use debugging stubs Prof. Asha N 14
- 15. Determining How Much Defensive Programming to Leave in Production Code Leave in code that checks for important errors Remove code that checks for trivial errors Remove code that results in hard crashes Leave in code that helps the program crash gracefully Log errors for your technical support personnel See that the error messages you leave in are friendly Prof. Asha N 15