From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-12 08:45:32
From: "Kevin S. Van Horn" <kevin.vanhorn_at_[hidden]>
> Handling of programmer errors
> There are many places where the documentation specifies that exceptions
> be thrown if some precondition is not met. Do you really want to
> this, or do you just want to say that the exception *may* be thrown? At
> time you do not want exceptions thrown for what amounts to programmer
> (e.g., unlocking a mutex that you do not have locked), as this throws away
> lot of useful information as the stack unwinds. At debug time it is much
> preferable for the program to dump core so that you can examine the core
> with a debugger and have full information on the context of the error. I
> recognize that a core dump is unacceptable for some production
> so it would be nice to be able to choose between the core-dump and
> options via a compile-time flag.
> In addition, I would suggest that even when you do throw an exception, the
> exception object should include the file and line number. (See discussion
> below for overview.html.)
This is mostly addressed by BOOST_ASSERT (good timing, isn't it.)
There is one more aspect to this, however.
In a formal specification, there are two options:
* defined behavior (usually an exception.)
* undefined behavior.
As a QoI issue, you can make the undefined behavior more convenient, for
example by using BOOST_ASSERT. _But_ there is absolutely no guarantee that a
code that makes assumptions about the nature of the undefined behavior is
portable (or will run at all.)
In contrast, you can _rely_ on the defined behavior of throwing an
exception, assuming a conformant implementation.
Strictly speaking "an exception is thrown when a precondition is not met" is
an oxymoron. Not meeting a precondition invokes undefined behavior.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk