From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-11 09:44:29
----- Original Message -----
> 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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk