Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-11 09:44:29


----- Original Message -----
From: <williamkempf_at_[hidden]>

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

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.

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.

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.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk