On Sat, Aug 13, 2005 at 07:52:37PM +0100, John Levon wrote: > 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.
Surprisingly so. > 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. Not if we tell the user and give him a choice to abort or to continue at his own risk. There are quite a few things that we should ASSERT on that are not crucial for the state of the system. If e.g. some cursor movement failed or some dialog does not display correctly, it is annoying and should be fixed at some point, but there is no reason for forcing a hard abort. > We've already implemented emergency saves and it usually works well. Usually yes, but even having to restart LyX might be more annoying than a button that's drawn a few pixels off. > 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. Well, so we agree at least here. Andre'
