Re: Runtime error reporting

From: williamkempf_at_[hidden]
Date: 2001-03-20 14:47:18

--- In boost_at_y..., Kevlin Henney <kevlin_at_c...> wrote:
> In message <030b01c0b108$9dbcba60$37781990_at_u...>, Greg Colvin
> <gcolvin_at_u...> writes
> >> As indeed a straight call to std::unexpected will do. What am I 
missing?
> >
> >A way to communicate what the error is to the unexpected_handler?
> 
> Of course. The hack goes much deeper than the code you showed :-> 
It's a
> little early, I guess I need more coffee before reading between the
> lines 8-)

For some applications this hack is beautiful!  However, for a Boost 
solution I don't know if I like it.  You can no longer use the 
unexpected_handler for what it was meant for while at the same time 
having a configurable "assert".  I'm not sure how this might effect 
real world applications, but it makes me nervous.

BTW, while on the discussion of a BOOST_ASSERT (or better name), we 
should also address one of the big issues with the C assert that's 
not been brought up yet.  To illustrate the problem, while adding 
assertions to Boost.Thread I've run into code that you naturally want 
to write like this:

   assert(pthread_mutex_lock(&mutex) == 0);

which is, of course, a bug.  When compiled with out NDEBUG the code 
is reduced to a no-op, which means the mutex is never unlocked.  So 
you wind up having to code the more verbose:

   int res = pthread_mutex_lock(&mutex);
   assert(res == 0);

which just makes the code harder to read and maintain.  MS did 
something right in this regard in their MFC library where they have 
an ASSERT() which is similar to the classic C assert and a VERIFY() 
which retains the expression in builds without NDEBUG but does not 
halt the program if the expression evaluates to false.

Bill Kempf