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

From: Kevin S. Van Horn (Kevin.VanHorn_at_[hidden])
Date: 2002-11-14 17:03:16

Peter Dimov writes:

> The new boost/assert.hpp is now in CVS, I'll copy it below for 
> convenience:

It's simplicity is certainly an advantage.

> The main difference between this version and the old assert.hpp is that
> BOOST_ASSERT now uses the standard assert by default,

Hmmm... I guess my previous objection to doing this by default doesn't 
really hold here, because if NDEBUG is defined the assert() is a no-op.
However, a couple of quibbles:

1. The proper C++ header file is <cassert>, not <assert.h>.

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.

> I've introduced separate BOOST_DISABLE_ASSERTS and 
> BOOST_ENABLE_ASSERT_HANDLER macros since relying
> on the BOOST_DEBUG "magic values" to control behavior seemed inferior.

I agree.  Nobody wants to try to remember such numeric codes.

> assertion_failed is declared but left undefined, the user is expected to
> supply a definition. Compared to a set_assert_handler approach, this has
> the advantage that the handler is guaranteed to be already active when
> static object constructors are being executed.

OK, I agree that this is cleaner, as long as the user only has to supply a 
definition when BOOST_ENABLE_ASSERT_HANDLER is defined.

> 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.

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.

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.  If you like, 
this could be in a separate header that #include's <boost/assert.hpp>.

Now I'll levy one criticism against my own Boost Assert proposal:

If you want assertions checked and exceptions thrown when they evaluate 
false for a production system, then you probably don't want to do any 
expensive tests.  However, during development you probably want to turn on 
all the checking and debugging options you can.  A distinction needs to be 
made between "light" tests and "heavy" tests; the option to throw an 
assertion probably only makes sense for "light" tests.

> there is no BOOST_ASSERT_MSG. I don't have a strong opinion here.

I included BOOST_ASSER_MSG because its equivalent in STLport seemed to be 
useful as I scanned through that code.  I don't have any experience in 
using STLport myself, though.  For those who have used STLport's debug 
mode, how useful have you found the additional error message information 
on failed debug assertions?

BTW, if BOOST_ASSERT_MSG is included, we'll have to make sure that this is 
still a no-op when BOOST_ENABLE_ASSERT_HANDLER is not defined and NDEBUG 
is.  In particular, we have to make sure that the error message doesn't 
get printed out (the assert() already turns into a no-op).