Error Handling

To paraphrase a well-known saying, "To error is human, to forgive is just good programming!". Every user whether maliciously or accidentally will provide bad input at some time. This is a fact of life we must live with as programmers. However, the bright spot of this problem is we control when the user can give us this bad input. We know the time and place when all input must occur and we hopefully know the format of the desired input; therefore, we must take responsibility for ensuring bad input does not propagate through the program. Error trapping procedures must always be agreed upon in advance between the programmer and the user or user representative and be well documented. At no time is it acceptable for an user input to unexpectedly terminate your program!

So what do you do protect yourself against bad input? The answer is simple, after any input you must first check the validity of the input before proceeding and then decide how to respond to bad input.

1. Validity Checking
   • Ensure input data meets the required type.
   • Ensure input data falls within the required range of allowable values.
   • Ensure there is enough input to complete the task or is there any input at all.
   • Ensure input will produce a valid answer, i.e., checking for the existence of a file before trying to open it.
   • Ensure extra input is properly discarded.
2. Responses - different languages provide different programming constructs to trap errors but the net effect should always be the same.
   • Terminate program - this may seem very extreme but depending on the required input and type of program may be your only choice. For example, in a file I/O based program when you are expecting an input matching a double but you get an input of all characters, you have very little choice but to terminate the program as no corrections can be made and no prompting the user for correct input can be accomplished. Whenever you must terminate the program you should as a minimum inform the user what you are about to do and why. This often means writing to a predefined log file or writing to the standard error device if this is a console application.
   • Correct and proceed - sometimes the input is of the correct type but just not in the range of acceptable values. The appropriate response is determined by the documented requirements. For instance, I may have documented in the requirements all input for variable A must be greater than or equal to 10.5 and if the input is less than 10.5 you should automatically increase it to 10.5. Correcting user input and proceeding is a form of 'I know what the user wants better than the user does' and this is always dangerous. Never attempt this approach unless it is well documented. In any case you should also log your actions to an appropriate file.
   • Prompt - this by far the most secure and whenever possible the most desirable approach. Inform the user bad input has occurred, why it was bad input and prompt the user for correctly formatted input. The prompt should include the desired type and format of the input required.