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:
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk