Clearly, there is the issue of what to do when you find a problem. A robust program keeps running in the presence of problems. A correct program always produces correct results. You cannot produce correct results when you have bad input data. Note that a crashed program will probably do less damage than one that continues operating with incorrect input data. It all depends on your threat model what is the proper behavior when you discover bad input. After all, life-critical systems cannot simply stop providing life support. (Arian 5 abort issue) If you are going to fail, a general rule is that failing early tends to be better than failing late; the failure point is closer to the root bug or problem. Also note that your code is assumed to be bad until you can show that someone else’s code contains the bug Good input checking can show this earlier and faster.
options include:
-
Halting (aborting) the program, with or without a stack dump, etc
-
Have the user retry or repeatedly retry (till when?)
-
apply a “standard” fix to the input data. For example, if a value is above the maximum, lower it to the max and continue.
-
log the failure
-
Given an error message to the user. Be sure to indicate what they can do to fix the problem; “File not found” as an error message is useless.
-
Is an input validation error a security problem?
