Re: assertions: does it matter that they are disabled in production?
On 2008-08-05 19:28, Phil Hobbs wrote:
marlow.andrew@googlemail.com wrote:
Assertions via assert.h (or cassert) are disabled in production and
have to be enabled via the NDEBUG macro. This is one reason I don't
use the assert macro. I always throw an exception that means a fatal
programming error has occurred. Am I the only one that does this?
Surely not. My reasoning is that I always want the checks on, just in
case. This means it is something I tend to do sparingly, after all,
loads of them might well create a performance issue.
All the std programming text tell us how good it is to use assertions
(I am thinking of books like OOSC(II)) but the mechanism they describe
is like cassert every time, i.e turned off in production. I have
noticed that it is hardly ever used on any C++ projects I have seen.
It doesn't seem to get much use in C libraries either but does seem to
have a slightly higher usage there.
Does this mean C++ programmers don't like such a C-like mechanism? Or
they don't don't like the fact that the assertions are disabled in
production? Or is there some other reason?
An assertion is a useful low-level mechanism for catching bugs near
where they live, rather than waiting until 100000 cycles later when the
error shows up someplace else.
In production code, you work really hard to ensure that the user doesn't
lose data. That means that you don't make the program spew its guts up
if it finds a zero-length string in a dialog box, say, or can't find
enough file handles to open a logfile. Those are great places for
assertions, or some similar C++ mechanism, precisely because you want to
catch them in development but ignore them or handle them gently in
production. The same is generally true of checking class invariants.
There are also lots of runtime checks that you do want to have in
production code (including some of the same ones as you'd put in
assertions), but you don't use assert() for that--if the user's data is
at stake, it's really really bad manners to call abort(). I'd chuck a
program like that in the bitbucket instantly.
I disagree, errors that you can handle you either handle locally or
throw an exception, you never use assertions, not even during
development. On the other hand there will always be (unless you write
only trivial programs) a few errors that you simply can not handle, in
which cases assertions are used.
The alternative is to either continue with faulty data (which is *much*
worse than abort()), or to throw an exception which you catch in main()
and terminate the application there. Unless you can generate a stack-
trace or get some other useful information that way it does not buy you
anything you would not get from normal assert(), except a bit more
complicated code.
--
Erik Wikstr?m
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]