In-Reply-To: <4343103A.6010007@dcook.org> darren@dcook.org (Darren Cook) wrote (abridged):
I think it is fair to assume people don't have assert(false) in code that is ready for release - it is just used temporarily during debugging.
No, it isn't fair to assume that. I have: if (e) { assert(false); throw "can't happen"; } or similar in release code.
But just to be sure OKAY_TO_USE_ASSUME should be off by default.
A single monolithic switch isn't practical. There is no way to switch OKAY_TO_USE_ASSUME on without first checking whether every piece of code in the program is OK with it.
If that is the behavior of __assume(false), or at least given that it is a reasonable interpretation of what it could do, then including __assume() in BOOST_ASSERT() seems a little dangerous.
Which brings up back to the start of this thread :-).
Quite so. I find I am repeating myself. -- Dave Harris, Nottingham, UK.
Dave Harris wrote:
In-Reply-To: <4343103A.6010007@dcook.org> darren@dcook.org (Darren Cook) wrote (abridged):
I think it is fair to assume people don't have assert(false) in code that is ready for release - it is just used temporarily during debugging.
No, it isn't fair to assume that. I have:
if (e) { assert(false); throw "can't happen"; }
or similar in release code.
Isn't that an abuse of assert? IOW, shouldn't you either make it exclusively a debug mode check, or make it a check in both modes? It seems that that should either become: assert ( !e ); or: if ( e ) throw "can't happen"; Why do you need both types of checks in the same place? -Jason
From: Jason Hise <chaos@ezequal.com>
Dave Harris wrote:
In-Reply-To: <4343103A.6010007@dcook.org> darren@dcook.org (Darren Cook) wrote (abridged):
I think it is fair to assume people don't have assert(false) in code that is ready for release - it is just used temporarily during debugging.
No, it isn't fair to assume that. I have:
if (e) { assert(false); throw "can't happen"; }
or similar in release code.
Isn't that an abuse of assert? IOW, shouldn't you either make it
Not at all.
exclusively a debug mode check, or make it a check in both modes? It seems that that should either become:
assert ( !e );
or:
if ( e ) throw "can't happen";
Why do you need both types of checks in the same place?
That way a debug build asserts, which likely gets a core dump, and a release build throws an exception. If the exception is a type that is never caught in the code except in main(), then main() can report the problem and exit. That gives a clean exit with a diagnostic in release builds, while giving the opportunity for post mortem debugging in debug builds. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: Jason Hise <chaos@ezequal.com>
exclusively a debug mode check, or make it a check in both modes? It seems that that should either become:
assert ( !e );
or:
if ( e ) throw "can't happen";
Why do you need both types of checks in the same place?
That way a debug build asserts, which likely gets a core dump, and a release build throws an exception. If the exception is a type that is never caught in the code except in main(), then main() can report the problem and exit. That gives a clean exit with a diagnostic in release builds, while giving the opportunity for post mortem debugging in debug builds.
No. An assert should not throw, not in release mode, not ever. If an assert fails, your program is now in an invalid state. Throwing an exception potentially causes lots of code to execute that is potentially dangerous. The correct thing to do is dump core immediately. Maybe try to save user data into into a separate location, taking care not to overwrite the last-known-good with potentially corrupt data, but that's it. Assert != exception. -- Eric Niebler Boost Consulting www.boost-consulting.com
From: Eric Niebler <eric@boost-consulting.com>
Rob Stewart wrote:
That way a debug build asserts, which likely gets a core dump, and a release build throws an exception. If the exception is a type that is never caught in the code except in main(), then main() can report the problem and exit. That gives a clean exit with a diagnostic in release builds, while giving the opportunity for post mortem debugging in debug builds.
No. An assert should not throw, not in release mode, not ever. If an
The code you snipped used assert(false) followed by throwing an exception. The assertion never threw an exception. IOW, belt and suspenders. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Eric Niebler wrote:
Rob Stewart wrote:
That way a debug build asserts, which likely gets a core dump, and a release build throws an exception. If the exception is a type that is never caught in the code except in main(), then main() can report the problem and exit. That gives a clean exit with a diagnostic in release builds, while giving the opportunity for post mortem debugging in debug builds.
No. An assert should not throw, not in release mode, not ever. If an assert fails, your program is now in an invalid state. Throwing an exception potentially causes lots of code to execute that is potentially dangerous. The correct thing to do is dump core immediately. Maybe try to save user data into into a separate location, taking care not to overwrite the last-known-good with potentially corrupt data, but that's it. Assert != exception.
Fine. But why not use an exception as part of the mechanism for saving some (hopefully) recoverable data?
Ian McCulloch wrote:
Eric Niebler wrote:
Assert != exception.
Fine. But why not use an exception as part of the mechanism for saving some (hopefully) recoverable data?
Because exceptions cause unwinding, and that will potentially cause *lots* of code to execute. You don't want lots of code to execute when you're in an unstable state. You want to call your emergency clean-up code, dump core and die, immediately. -- Eric Niebler Boost Consulting www.boost-consulting.com
Ian McCulloch wrote:
Eric Niebler wrote:
Assert != exception.
Fine. But why not use an exception as part of the mechanism for saving some (hopefully) recoverable data?
Because exceptions cause unwinding, and that will potentially cause *lots* of code to execute. You don't want lots of code to execute when you're in an unstable state. You want to call your emergency clean-up code, dump core and die, immediately. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (2)
-
brangdon＠cix.compulink.co.uk -
Eric Niebler -
Ian McCulloch -
Jason Hise -
Rob Stewart