strcat+strcat+strcat == baaad"

[Dimitrie O. Paun]

On December 9, 2002 05:29 pm, vkxzjq6lg at 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.

-- 
Dimi.