Re: [boost] UBLAS_CHECK

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-10-04 05:23:46

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Tuesday, October 01, 2002 2:56 PM
Subject: Re: [boost] UBLAS_CHECK

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

Thanks, I'll adapt to that later.

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

Agreed.

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

Yes.

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

Agreed.

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

OK, in certain contexts debug/release builds and bounds checking
enabled/disabled are 'orthogonal'. The default cases are debug with bounds
checking enabled, release with bounds checking disabled. In debug mode the
default checking mode should use assertions. I'll think about it.

Thanks

Joerg