Re: [boost] Re: Runtime error reporting

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-03-20 15:08:16

From: <williamkempf_at_[hidden]>
> --- 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.

I've never yet seen a real world application of unexpected_handler,
but perhaps someone here can enlighten me.

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

Yes, this is good.