Re: [boost] Proposed Boost Assert -- once again

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-11-15 08:11:48

From: "Kevin S. Van Horn" <Kevin.VanHorn_at_[hidden]>
>
> 1. The proper C++ header file is <cassert>, not <assert.h>.

True. The "improper" header has the advantage that it's universally
available, though, and there is no other difference between the two, as the
macro assert isn't std-namespaced.

> 2. I think using familiar terminology is preferable.  Developers already
> know what NDEBUG does and how to use it, so I would prefer that
> BOOST_DISABLE_ASSERTS be renamed BOOST_NDEBUG.

No strong opinion, although I find it hard to believe that BOOST_NDEBUG
could be more understandable than BOOST_DISABLE_ASSERTS.

> > there is no explicit support for throwing exceptions, and no standard
> > exception class is defined. (Although it is trivial to define a handler
> > that throws.) This is intentional. I don't believe that we, at Boost,
want
> > to encourage this particular programming practice (assertions that
throw.)
>
> I disagree, on two counts:
>
> 1. I've dealt with enterprise systems that do some run-time checks, but
> for which crashing and core-dumping is not an option.  In this case it is
> preferred to abort the transaction (throw an exception), log the error,
> and get on with handling other transactions.

Agreed. This is why the capability is supported. assertion_failed() is
allowed to throw.

This doesn't mean that in general throwing exceptions when assertions fail
is a good programming practice. Far from it.

Providing direct support in a Boost core header effectively amounts to a
"Boost seal of approval", i.e. "we at Boost think that this is a good
programming practice and we want to encourage its use." Do we? I certainly
don't.

> 2. A number of the Boost libraries currently throw exceptions for logical
> errors.  During development, I would rather that these do an assert(), so
> I can inspect the core dump with my debugger.  Rather than fight over
> which is the correct behavior, it seems preferable to simply make it a
> user option.  I've been counting on Boost Assert to provide that
> functionality.

Fighting for which is the correct behavior is the Right Thing(tm) to do.
First, because it will improve the libraries in question, second, because
BOOST_ASSERT affects _all_ Boost libraries.

> One might argue that a user can always get throwing behavior by using
> BOOST_ENABLE_ASSERT_HANDLER, but I am of the opinion that one should
> provide some standard options for commonly-desired behavior.

Yes, that is exactly what I am arguing. Throwing an exception from
BOOST_ASSERT is undesired behavior. I don't want it as a standard option.