On December 9, 2002 05:29 pm, vkxzjq6lg@cswebmail.com wrote:
Do you agree with the way I've explained how I see the difference between redundant defensive programming and detecting and reporting problems which need to be fixed? If not, where do you differ and why?
Let me try to explain a bit more what I mean.
There are two kinds of error conditions: 1. Programming Bugs: this include having inconsistent state, a NULL pointer when it should never be NULL, etc. 2. External Errors: other component failing, disk full, etc.
What I'm saying is that for (1) we should die (most of the time), and for (2) we should fail gracefully, and seldom signal the problem.
You see, this classification depends on categorizing the code into internal and external.
Internal code is what we control (such as the implementation of the a control, or a component, etc); in such internal code we get to decide the invariants, and it's OK (and preferable) that we crash if such an invariant doesn't hold true. I don't think it's acceptable to add tests all over the place that print error messages: it bloats the code, makes it slower, and uglifies it to the point where you can't figure out what you're actually trying to do. In such cases I consider such checks to be detrimental.
For external code, we no longer have the luxury to do what we want. Most (all?) Win32 APIs don't crash on NULL pointers, and so we should not crash either. Also, outputting a message in such a case is not needed -- this is normal behavior, and outputting messages just clutters the code, as well as the output. Again, such messages are detrimental. A few of the Win32 functions go a step further (oh, the horror!), and accept bad pointers without crashing. We should replicate such brain-dead behavior only if we know that (a) Windows does it this way in all versions, and (b) there are significant apps that depend on such behavior.
As you can see, there are few cases where outputting messages is waranted. It is mostly in places where we know we don't implement the entire specification. Too many messages are as bad as too few. We already output quite a few, adding tests and ERRs/WARNs all over the place is not a good idea.