[Clam-devel] refactoring backends (2)

[David García Garzón]

CLAM_ASSERT provides throw on release, but i shoud had RTFA before replying as 
this is not the only nice feature ENFORCE provides. It uses a nice idiom uses 
some tricks that we should use for asserts to get richer messages. That's 
something we have been thinking about, just to get rid of that verbose idiom: 

http://clam-project.org/wiki/Devel/CLAM_idioms
if ( error-condition )
{
  std::ostringstream os;
  os
    << "err message: "
    << "some var: " << var
    << std::flush;
  CLAM_ASSERT(false, os.str().c_str());
}

To something that reensembles:
CLAM_ASSERT_MSG(condition) 
	<< "err message: "
	<< "some var: " << var;

But, of course, if this implies a change in the user code, in something that 
is as ubiquitous as CLAM_ASSERT, that's not a solution unless it pays the 
price.

David.


On Monday 08 June 2009 15:54:23 David García Garzón wrote:
> Yes, that's just what CLAM_ASSERT does. Aborting in debug, throwing in
> release. The one that it is removed on release is the CLAM_DEBUG_ASSERT,
> and we don't recomend using it unless the overhead of the check is in a
> bottle neck.
>
> CLAM asserts also provide backtrace dumping  (in linux) and programable
> handling callback. We had a callback that we used on graphical apps that
> showed a dialog before crashing but we removed it temporary because when
> the assert was done in the processing thread (within a Do) it could not
> access the gui thread safely. This is another one of the refactorings we
> should do on the backends: handling unhandled exceptions and failed
> assertions.
>
> See the doxygen for more information:
> http://clam-project.org/doc/CLAM-doxygen/Assert_8hxx.html
>
> David.
>
> On Monday 08 June 2009 15:08:42 dirk.griffioen wrote:
> > Hi,
> >
> > Would clam be interested in the ENFORCE idiom? Basically these are
> > asserts, but they are kept in release mode and throw(). The rationale
> > you can find here: http://www.ddj.com/cpp/184403864
> >
> > I have found they lead to much smaller and safer code as for instance
> > preconditions/invariants are 'enforced'.
> >
> > For example, before:
> >
> >
> > and after (please note the example is not too good: destuctors should
> > not throw ...)
> >
> >
> >
> > It generates errors like this:
> >
> >
> >
> > But this might be too much what CLAM_ASSERT already does ...
> >
> > Dirk
> >
> > PS - attached the header