Boost logo

Boost :

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, gregod at, cpdaniel at, john at