[boost] Re: Invariants Library

From: Dan W. (danw_at_[hidden])
Date: 2004-01-02 10:33:42

Reece Dunn wrote:
> Dan W. wrote:
>> Thorsten Ottosen wrote:
>>> I recall that one could choose not to remove preconditions
>>> from release builds.
>> In public interfaces no, as the preconditions are in the extracted 
>> header, but the preconditions in private functions, and all 
>> non-public, implementation classes in the object code, preconditions 
>> are gone.
>> Wouldn't make sense to keep them without source code to debug.
> Surely, it would make sense to keep them in (disregarding the source 
> code problem for now). Consider:
> 
> int main()
> {
>   std::cout << "Enter a number: ";
>   float f = 0.0f;
>   std::cin >> f;
>   std::cout << "square root = " << sqrt( f );
>   return( 0 );
> }
> 
> Granted, you could add an explicit check:
...snip...

Allright, first let me apologize to Thorsten: I read his paragraph too 
quickly and thought it said "one could NOT CHOOSE to remove" instead of 
wha he was really saying, "one could choose NOT to remove". So, my 'no' 
meant to say, "yes, you canNOT remove them from public interface classes 
because they are with the headers...".  And I was just making coffee and 
thinking about that and he's right, you could choose NOT to remove the 
preconditions, though I'm not sure about the wisdom of such feature. Let 
me explain:

What syntax checks, assertions, exceptions, and exit() all have in 
common it that they try to fight problems. The earlier in the process a 
problem is dealt with, the better;  so best are language checks, 
followed by compile-time assertions, followed by debug-mode assertions 
and DBC, followed by exceptions, and then exit().

Exceptions could be further subdivided in terms of policy:

   Best are Beta release exceptions that log problems to a file and 
email it back to the programmer.
   And then there are non-Beta exceptions... and here's the trouble.

The trouble is that code running in the field may encounter situatios 
that either,
   A) Were unforseen (un-imaginable input, or cling-on bugs),
   B) Were forseen but just too deliriously bad.

When one of these things happens, the question is, what do we do?

I have a very simple example, and a real-life one, to illustrate what 
I'm about to propose to you; --namely, that there should NOT be a 
*default policy* being assumed, either by language or library.

I once designed an embedded application, an Engine Controller; 
--basically, an automatic fuel and starter controller, and engine health 
monitoring. The question came at one point: "If the oil pressure switch 
closes, should we stop the engine?" Most immediately said yes. I wasn't 
sure, because an engine could run safely for a few extra minutes, during 
which time I could sound an alarm. Then someone said: "Wait a minute!.. 
Our controller is often used to control generators at hospitals. We 
cannot shut down the engine at all, or people on respirators will die! 
We may ONLY sound an alarm!"

You see what I'm getting at?  For the same product, identical 
application, yet, for one client, safety may mean "save the life of my 
expensive engine"; for another it may mean "keep my patients alive!".

Remember the case of that Arienne 5 rocket that crashed due to a 
software glitch?  There was a thread that monitored horizontal wind at 
the lunch pad.  It was supposed to stop working 40 seconds after launch, 
but didn't because the countdown was stopped and then re-started too 
soon, so it got confused.  About 3 minutes into flight, its output 
wasn't even being used, but it saw winds that were higher than the range 
of its input, threw an exception, and all 3 computers crashed.

I think that exceptions, in fact, should have two policy sections: 
Terminate and KeepAlive, both of which should be mandatory coding, and 
the clients should be able to choose the policy at compile time, or 
defer it to run-time, for the user to specify.

But this is not the problem of assertions and DBC. Assertions and DBC 
are just fuses to debug code.  They can have, and must have, a default 
policy.  This is why I would be terribly disappointed to see DBC getting 
mixed up with exceptions or error logging.  I think most of us 
programmers are already confused enough, as to what to use, when.

Cheers!