Re: Boost.Assert

From: Msk_at_[hidden]
Date: 2001-11-14 02:25:01

--- In boost_at_y..., Ullrich Koethe <u.koethe_at_c...> wrote:
> Ullrich Koethe wrote:
> > 
> > If I'm not mistaken, a similar mechanism is already part of the 
proposed
> > version 2 of the test tools library. Please check it out in the 
boost
> > files section.
> > 
> 
> Oops, forgot to quote the reference:
> 
> Msk_at_X... wrote:
> > 
> > if( num_widgets > max_widgets )
> > {
> >     throw logic_error(
> >         BOOST_ERROR_MESSAGE << "num_widgets = " <<
> >         num_widgets << " is greater than maxwidgets = " <<
> >         max_widgets );
> > }
> > 

Ah yes, I see I've re-invented another wheel. :-)  Not having
looked into the innards of test tools v2 before, I hadn't noticed
your version until you pointed it out.  My version adds an implicit
conversion operator and factors out the formatting a little
differently, but the core design is essentially the same.

Correct me if I've misread your code, but it appears that the
BOOST_MESSAGE in the test tools is quite specialized for the
specific purpose of doing testing - as well it should be.
What I'm looking for, however, is the same basic trick with
ostringstream, but with a more general interface that application
programmers can easily modify and use when they write regular
(non-test) code.

In our project we found that although the implementation of
this kind of thing is pretty simple, the beneficial effect on
overall code quality is profound.  With a few additional
macros provided like:

#define VERIFY(cond,msg) do{ if( !(cond) ) throw logic_error( \
        BOOST_ERROR_MESSAGE << msg); } while( false )

our programmers can write simple statements like:

VERIFY( p!=0, "no widget supplied" );
VERIFY( p->m_status==normal,
        "abnormal widget, state = " << p->m_status );

(Yes, these look a whole lot like asserts.  That's the whole
point - it's a simple, familiar syntax.)

This code is just easy/short enough that people actually write it.
There seems to be a threshold effect at work, because if things
were any longer/harder than this, then somehow haste and laziness
seemed to triumph and the check statements never got written.  Since
the system involved runs 24x7 and simply logs and (usually) recovers
from all errors, problems can be difficult to reproduce and it is
really valuable to have any extra information we can get in the logs.

I think it would be useful for boost to have something like this
documented for general use.

- Michael Kenniston