"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
No, I really mean an exception. Asserting while saving isn't a good thing; the program goes down, taking the user's document with it. Saving into a different format may be successful and the opportunity shouldn't be denied.
An assertion can always be set up to throw in release mode. I was thinking of BOOST_ASSERT or something like it, not plain old assert.
No, no. :-)
An assertion looks like this:
Requires: Cond.
Yes. Why wouldn't you want this function to require that condition? Anything else is a coding error.
An exception looks like this:
Throws: pointer_conflict when Cond. Exception safety: If an exception is thrown, there are no effects.
A release build with assertions disabled that silently produces unreadable files isn't a good thing, either.
But don't you want to be able to debug this coding error when you make it during development?
Yes, probably. But I don't want the undefined behavior.
BOOST_ASSERT doesn't have to induce undefined behavior. I just want a clear separation between coding errors and other conditions. -- Dave Abrahams Boost Consulting www.boost-consulting.com