Re: assertions: does it matter that they are disabled in production?
In article <4bj6a45fm44lj5n9d1a5125ufl65gjig7b@4ax.com>,
Geoff <geoff@invalid.invalid> wrote:
And what's wrong with
SOME_ASSERT_MACRO(i != 0);
if (i != 0)
val = x/i;
else
return FAILURE_CODE;
// or alert user
// or ...
The assertion assures a nice trap while in development & test, calling
attention to the fact that an assumption has been violated and the runtime
check assures that when the assertion code isn't there in release that
something is there to catch it anyway.
Tell me how you tested it. Assume you have an ASSERT macro that fires
but doesn't abort. Either:
The ASSERT never fires, in which case you haven't fully tested the code
that runs after it, which might put your program in a worse
unpredictable state than the one it would be in if the ASSERT just
aborted.
The ASSERT fires and you remove the buggy code. Once the buggy code is
removed, you can no longer fully test the code that runs after the
ASSERT.
The ASSERT fires and you leave in the buggy code, in which case you are
shipping a buggy product that you know can get into an unpredictable
state.
I'm with Walter on this one. An ASSERT detects a programming error, and
your program is in an unpredictable state. You have to get it back into
a predictable state. On some systems, this is accomplished by aborting
and restarting. On others, life is more complicated. But just ignoring
the detected programming error is never the right thing to do.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> 773 961-1620
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]