Re: any_function (callback) library

From: williamkempf_at_[hidden]
Date: 2001-04-11 12:34:57

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> 
> ----- Original Message -----
> From: <williamkempf_at_h...>
> 
> > In fact, other
> > languages throw exceptions on failed assertions to further cloud 
this
> > argument.  Saying that this is exactly what assertions are for 
does
> > not help to argue your case, or to help people like me figure out
> > when to use what kind of error handling.
> 
> I note that C++ platforms (MSVC) that throw exceptions when an 
assertion
> fires produce undesirable interactions with just-in-time (JIT) 
debugging
> that can make things much more difficult for the person trying to 
debug the
> program.

C++ platforms (MSVC) that throw exceptions when an assertion fires?  
Some alternative library assertion packages may do this, but none 
that come with MSVC throw exceptions.  I was speaking of other 
languages here.

In any event, the JIT debugger handles exceptions as easily as it 
does assertions, dropping you into the code at the point where the 
exception was thrown.  So I don't know what you're trying to say here.

> Other languages have different exception models, so its hard to 
make a case
> about C++ exception use policy on that basis. For example, I would 
have no
> serious objections to throwing an exception from assert() if the 
exception
> could carry a snapshot of the program state (before unwinding) with 
it. This
> sort of thing is possible with LISP systems.

It's possible with C++ as well.  There's nothing in the standard 
preventing this that I can see.  Granted, it's not required either, 
which may be what you're getting at, but it's also not required for 
an assertion to be able to give you this type of information either.

> One final point:
> 
> if your function is documented to throw under condition ~X, then X 
is not a
> really precondition for your function: the behavior under ~X should 
be
> well-defined. I don't see any point in saying "f() requires X, but 
if ~X, it
> will throw".
>
> If your function is documented to require X, it is allowed to 
throw, assert,
> or do anything else it likes under condition ~X. Whether or not 
throwing is
> advisable can be taken on a case-by-case basis. In some 
applications where
> recoverability is critical, it may make sense to assert in debug 
builds but
> throw in release builds.

~X == Y is always a valid possible boolean equivalancy, so I don't 
see how this designation can be used.
 
> I don't think it would be fair to say that I violate my own rules: 
I'm
> saying it's a choice you have to think about. There are tradeoffs. 
Not every
> programming decision can be made by prescription.

I didn't single out any one person when I said "they" break their own 
rules.  By your own admission here you don't have rules but instead 
have what I'd consider loose guidelines.  Every time this subject has 
come up, however, the arguments always state hard and fast rules.  To 
further complicate matters, even if you take these rules as loose 
guidelines instead, every person seems to have their own set.  I've 
never seen this topic come up where any kind of concensus is 
reached.  I'm truly at a loss to understand when and when not to use 
exceptions.

Bill Kempf