I agree completely, but I come from an Assembler background where you HAD to sanity check EVERYTHING. The volume of "buffer overflow" issues in C programs boggles my mind. Even after I started coding in C, I still maintained a similar level of paranoia regarding input validation. It's not like it's all that hard to limit the size of what you accept, folks!
Lint helps find these things in C very well! (And others you others you most likely have not thought of... 8-)
But some languages make it hard to implement certain kinds of checking properly. I've seen, for example, Cobol programs fail with 0C7 errors because some file field that was supposed to contain packed data doesn't. Certain assumptions are made, but occasionally things go wrong.
So what SHOULD the application do about something like that? The answer goes back to that point I made in an earlier item about data integrity. If you don't KNOW what the field is supposed to contain, stop everything, report the failure, and let someone fix it. It seems inconvenient, but in the long run, often it's the safest course.
This is good *IF* it is not a critical system. If the application is moving billions of financial transactions around the world and it costs brokers millions of dollars for every minute of down time just "stop everything, and let someone fix it" is not a good answer. The application needs to identify the failure point, establish what is likely good or bad data and charge ahead. (After leaving a solid trail of bread crumbs for someone to follow....)
- Dale
