Re: [boost] Design and documentation of Boost.Threads

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
*will*
> be thrown if some precondition is not met.  Do you really want to
guarantee
> this, or do you just want to say that the exception *may* be thrown?  At
debug
> time you do not want exceptions thrown for what amounts to programmer
error
> (e.g., unlocking a mutex that you do not have locked), as this throws away
a
> 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
dump
> with a debugger and have full information on the context of the error.  I
> recognize that a core dump is unacceptable for some production
environments,
> so it would be nice to be able to choose between the core-dump and
exception
> 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.