Re: [boost] UBLAS_CHECK

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-10-01 07:56:43

From: "Joerg Walter" <jhr.walter_at_[hidden]>
> > >          virtual void raise () {
> > >    #ifndef BOOST_NO_EXCEPTIONS
> > >              throw *this;
> > >    #else
> > >              abort ();
> > >    #endif
> > >          }
> >
> > This should probably just call boost::throw_exception(*this), allowing
> > BOOST_NO_EXCEPTIONS users to handle the exception.
>
> Where do I find throw_exception? I searched the 1.28.0 distribution and
> found a definition in the lambda library only?

boost/throw_exception.hpp in the CVS.

> > Also, I agree that BOOST_UBLAS_CHECK should just assert (by default).
>
> I noticed recent discussions regarding the question, whether preconditions
> should assert. I'm still unsure.
>
> > It's
> > OK to provide a "throw exception" option, of course; even so, throwing
an
> > exception only in debug builds seems very odd.
>
> This is not odd, if you're counting flops.

It's odd. :-)

Typically exceptions-on-precondition-violations (a questionable practice
except in certain contexts) are used when _the program_ wants to detect
precondition violations, not the tester.

In other words, using exceptions for precondition violations turns
precondition violations into a legal execution path, part of the program
semantics.

It doesn't make sense to do this only in debug builds, as debug builds are
typically used for testing, and when testing, you don't need the program to
self-diagnose bugs, you need the debugger to immediately pop up at the
moment a bug is detected. That is exactly what assertions are designed for.

On the other hand, it sometimes (rarely) makes sense to try to detect logic
errors from within the program and attempt to recover gracefully, but only
in release builds, as this is what the customer would be using. Not a good
idea in performance critical contexts, of course.