RE: [boost] casts, exceptions, and asserts

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-26 17:35:39

----- Original Message -----
From: Darin Adler <darin_at_[hidden]>
To: Boost <boost_at_[hidden]>
Sent: Friday, October 26, 2001 7:13 PM
Subject: Re: [boost] casts, exceptions, and asserts

> on 10/26/01 3:00 PM, Fernando Cacciola at fcacciola_at_[hidden] wrote:
>
> > In other words; I think that the correct distinction is not between
asserts
> > and exceptions, but between asserts and error detection.
> > The later uses the exception mechanism explicitely.
> > The former is implementation specific. It can be implemented in terms of
a
> > thrownn exception invisible to the user. (I'll explain below why this is
a
> > good idea)
>
> I agree -- that's precisely what I was trying to say in my original
message.
> When you say "asserts" here, that's my "function type B"; your "error
> detection" is my "function type A". I don't think "asserts" is a good name
> for something that could be an assert or an exception or nothing at all.
>
> So I think that you and I, at least, see eye to eye on this.
>
> I think you and I can both agree that Boost should continue to use
> exceptions for "type B" purposes. But we also both would like a
configurable
> system for "type A" checks rather than using <cassert> directly,
defaulting
> to <cassert>. Code in Boost that currently uses <cassert> directly should
be
> changed to use a new configurable system; perhaps we can call it
> Boost.Assert. I believe this has been discussed a bit in the past.
>
Totally agreed.
I would also like to see some level of 'error detection' formal system.
Throwing an exception is right, but there can be additional tools for
debugging purposes.

> > Regarding numeric_cast_traits<>, I agree that we need the 'assert in
debug
> > mode' only versions.
>
> I'm glad you agree.
>
> > Anyway, notice that the optimized code that I presented
> > actually bypasses the range checking when it determines at compile time
that
> > it isn't necessary, for instance, when converting from 'float' to
'double'
>
> I did notice that you optimized away the range checking. And this is
great,
> but beside the point. A check that never fires and the lack of a check
have
> the same behavior.
>
Yes.

So,
Should we sketch a "defect management configurable framework"?  What about
the debugging tools submitted by Brian Parker a few days ago? Can that be
made to fit here?

P.S: We also agree that assert is probably a bad name because it carries a
fixed semantic, which might or might not match with the semantic of the
system we are discussing here; though I can't think of a good name right
now.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com