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