On Sat, Aug 13, 2005 at 01:56:22PM +0200, Andre Poenitz wrote: > Btw, I don't really like BOOST_ASSERT (as well as the 'traditional' > ASSERT) as it does not offer a possibility to specify what should happen > in the failure case. Most failure conditions are not critical for the > appliction, but simply continuing in the ordinary code path might not be > acceptable either.
Predictably, I have to disagree. An assertion signals that something is wrong; by their very nature we cannot be positive as to what the issue is. In particular the risk of silent corruption becomes a lot larger. We've already implemented emergency saves and it usually works well. We simply must grind to a halt when internal state isn't what we expect, because we really don't have any way of knowing the consequences (sure, maybe we got a dontlike for some trivial reason, but maybe we got it because we're reading freed memory). > ... something equivalent to BOOST_ASSERT without actual bombing > ... issue some warning, maybe offer the option to abort The user (like the program) has no way of knowing whether it's safe or even meaningful to continue. > These asserts should not be left out in an optimized build. > This is much more robust than crashing unconditionally or > removing the ASSERT code from released versions. I'm 100% for retaining asserts in the production code. regards, john
