Re: Assertion vs Exception Handling
On Mar 12, 9:53 pm, Ian Collins <ian-n...@hotmail.com> wrote:
On 03/13/10 01:21 AM, Leigh Johnston wrote:
"Ian Collins" <ian-n...@hotmail.com> wrote:
On 03/12/10 11:36 PM, Leigh Johnston wrote:
"James Kanze" <james.ka...@gmail.com> wrote:
But most of the time, assertions will be active in
Sigh. What do you mean most of the time? We have been over
this before. By default assert does nothing in release
mode which is the way it should be. Release mode = NDEBUG
= "not debugging" = no op assert.
That depends how you define "release mode"
Most of the software I have released was released with
assertion on and most of the code I use (including my
preferred C++ compiler) has them enabled.
I'd rather have a bug report with a core file than one
Release mode asserts are desirable only when a higher degree
of defensiveness is required which depends on the
application domain in question. There is a reason why assert
does nothing when NDEBUG is defined.
Yes there is, you can turn them off. A lot of applications
don't. It may depend on the platform, but most Unix
applications I use (and write) have asserts on; as I said, a
bug report with a core file than one without. If used
correctly, asserts trap the unexpected and protect the
integrity of the application's state. I bet whatever C++
compiler you use has them turned on.
The standard requires assertions to be active unless they are
explicitly disabled (by defining NDEBUG). The standard also
very explicitly allows including <assert.h> multiple times,
changing whether NDEBUG is defined between the inclusions. The
intent is clearly to allow turning off assertions in a very
controled manner, since you can include <assert.h> multiple
times, and the definition of assert will change each time.
All of the compilers and IDE's that I know (Sun CC, g++, Visual
Studios) have "defaults" set for just playing around. They're
fine if you just want to quickly try something out, but you
wouldn't use them in production code. This is doubtlessly
because there is no one set of defaults that would be
appropriate for all types of production code, so anyone
developing code professionally will read the compiler
documentation, and decide what options are appropriate for his
Release mode is a nebulous concept; it means different things
to different people.
Release mode means whatever set of options are used in the code
you release. If at all possible, that will be the same set as
you used to develop the code---I don't like the idea of
releasing code compiled with different options than those I've
tested. There are, however, valid reasons for differences: you
might not what the debugging symbol tables in the released code,
for example. There are even specific cases where you might want
to turn off assertions, at least in critical sections of your
code, and under Windows, it's usually appropriate to catch
SIGABRT, and to intercept structured exceptions, in order to
prevent the silly pop-up window you'll get otherwise.