Code Complete, Chapter 8:Defensive Programming

 

 Designing how to handle errors and exception is a kind of "high level design", which should be performed during the phase of system design. There are basically three types of attitude to handle the invalid inputs for the programming viewpoint.

 1 Garbage in, garbage out
 2 Garbage in, message out.
 3 No garbage allowed in.

From the softwate viewpoint, when it meets a error, there are two ways to handle it.

 1 Correctness. It means never returning an inaccurate result. The system would stop to proceed.
 
 2 Robustness. It means always trying to do something to allow the system keep operating. (Mirosoft XP)

When design the general apporach of handling errors, it is useful to try to find out a "saved room", outside the room are the preconditions that if entering the room, all the precondition should be meets. Inside the room , error should be handled by "exception mechanism".  Assertions are used to build the "Barricade", something like firewall. "try-catch" blocks are used to build the "Exception mechanism". One approach to handle exception is making "Exception mechanism" centerlized.

Error-handling typically checks the bad input data; Assertions check for bugs in the code where the preconditions are not satisfied.

To find out the "saved room", identifying which are the public interfaces is important, as the public interfaces are the place begin to get input and thus probably get bad input. In a class, the private methods can be always assumed that "no garbage in".

There are two types of code existing during the software life, development code and production code. In the development code both the debug codes and exception-handling error are existing; But in the production code, most of the debug code need to be removed, at least all the "assertions" need to be switched off. So don't make any function depending on assertions.

Tips: It is useful to create some scripts or precompiler to handle switching on and off the debug codes.
Tips: Generally speaking, for any given error, aroutine will use either an assertion or error-handling code, but not both.
Tips: Remember assertion never handle an error, it just make warning when error taking place.
Tips: The decison of  how to handle error is designed, then this way should be undertaken consistently.
Tips: Private methods don't do any type of error handling, so assertions normally used heavily in this kind of methods.
Tips: Too mcuh defensive programming creates problems of it own.
Tips: Production code should handle erros in a more sophisticated than "garbage in, garbage out".

 
Here are error handling techniques, which should be depending on the software is required to be correctness or robustness.
-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.