assert vs. std::logic_error?

[werasm]

Hi all,

Care to share your thoughts on this, or point me to
some thoughts already shared.

My thoughts are like this (from a systems point of view):

When I have logic errors outside of my system (or software)
boundaries I throw a logic error (interface specification not
met, etc). This implies the system is logically erroneous. I
do not regard things like failure to read files or access hard-
ware in this light. For those I use runtime error (but that
steers from the question).

When I have errors due to requirements change inside my
software boundaries that cause code to break, I assert. I
try and do this in code that I know will be tested (this
may be hard to determine, but typically startup code).

Apart from above mentioned, I'm still on two minds on the topic.
Any other thoughts welcome.

Regards,

Werner

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-11-21 16:54, werasm wrote:

Hi all,

Care to share your thoughts on this, or point me to
some thoughts already shared.

My thoughts are like this (from a systems point of view):

When I have logic errors outside of my system (or software)
boundaries I throw a logic error (interface specification not
met, etc). This implies the system is logically erroneous. I
do not regard things like failure to read files or access hard-
ware in this light. For those I use runtime error (but that
steers from the question).

When I have errors due to requirements change inside my
software boundaries that cause code to break, I assert. I
try and do this in code that I know will be tested (this
may be hard to determine, but typically startup code).

Apart from above mentioned, I'm still on two minds on the topic.
Any other thoughts welcome.

The way I see it an assert should only trigger if there is something
wrong with your code and an exception should be thrown if something goes
wrong during the execution. In other words, you use asserts to check the
invariants that your code should preserve. As Alan said: a triggered
assert indicates a bug.

--
Erik Wikström

[James Kanze]

On Nov 21, 8:25 pm, Erik Wikström <[e-mail]:

On 2007-11-21 16:54, werasm wrote:

Care to share your thoughts on this, or point me to
some thoughts already shared.

My thoughts are like this (from a systems point of view):

When I have logic errors outside of my system (or software)
boundaries I throw a logic error (interface specification
not met, etc). This implies the system is logically
erroneous. I do not regard things like failure to read files
or access hard- ware in this light. For those I use runtime
error (but that steers from the question).

When I have errors due to requirements change inside my
software boundaries that cause code to break, I assert. I
try and do this in code that I know will be tested (this may
be hard to determine, but typically startup code).

Apart from above mentioned, I'm still on two minds on the topic.
Any other thoughts welcome.

The way I see it an assert should only trigger if there is
something wrong with your code and an exception should be
thrown if something goes wrong during the execution. In other
words, you use asserts to check the invariants that your code
should preserve. As Alan said: a triggered assert indicates a
bug.

I think his problem is more semantic. The name logic_error
sounds very much like a programming error, which should usually
be handled by an assert, and not an exception.

Roughly speaking, I tend to think of the opposition logic_error
vs. runtime_error as something like domain_error vs.
range_error. It is a logic_error to call sqrt() with a negative
value, a runtime_error if exp() overflows. Depending on
context, either or both can be considered as a programming error
(and thus should be handled by an assert)---the programmmer
didn't sufficiently validate his input. In practice, however, I
can imagine that there are cases where catching the exception is
the simplest way of validating the input: rather than an
explicit test up front (which could be extremely complicated, if
the later processing involves complex expressions or a lot of
iteration), just catch the exception, and do whatever you would
have done if the input didn't validate. (Now if only the math
routines were guaranteed to generate such exceptions:-).)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[werasm]

On Nov 22, 11:17 am, James Kanze <[e-mail]:

I think his problem is more semantic. The name logic_error
sounds very much like a programming error, which should usually
be handled by an assert, and not an exception.

Yes precisely, that was what originally caused me to ask the
question.

Werner

[Roland Pibinger]

On Fri, 23 Nov 2007 09:31:14 +0100, "Alf P. Steinbach" wrote:

>* Roland Pibinger:

>asserts and tests are not related. Production code which is tested
contains no assets.

That's a good way to transform easily identifiable bugs into more
nebulous general "instability".

Any real-world example for programs that ships with asserts?
Another argument against asserts in production code is performance:
asserts significantly slow down the program (if they don't you haven't
used enough asserts in your code).
BTW, asserts seem to be a C and C++ only thing. For my work I mostly
use Java and I have neither used nor missed asserts. They are not
necessary in that environment.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[werasm]

On Nov 24, 3:32 pm, "Alf P. Steinbach" <[e-mail]:

Try to google up "java assert".

Interesting. The first hit:

(http://www.cs.helsinki.fi/u/vihavain...avaAssert.html)

affirms to a large degree the whole lifejacket in the ocean thing.

Regards,

W

[James Kanze]

On Nov 24, 3:32 pm, "Alf P. Steinbach" <[e-mail]:

[...]

Another argument against asserts in production code is
performance: asserts significantly slow down the program (if
they don't you haven't used enough asserts in your code).

Sorry, that's mostly bullshit, in the technical meaning of
bullshit. A slowdown due to assertions means you're using
assertions incorrectly, to check too complicated stuff.

Actually, it's more of a misleading half-truth. The reason you
don't use assertions to check too complicated stuff is precisely
because they'll slow things down. Imagine a function which
processes a large set of data, with a post condition that the
data are sorted. I'd certainly like to assert that post
condition, since it's part of my contract. I don't, of course,
because verifying that a large array is sorted *is* too
expensive to leave in production code.

What's probably needed is some sort of multi-level assertions,
depending on run-time, so that you can turn off the expensive
asserts, and leave all of the rest in. Ideally, anyway---in
practice, with a little care, I've never had any real problems
with the current situation.

Namely that there is a runtime cost associated, an engineering
trade-off, and so you really want to have an assertion system
in place where you can shut down the most costly ones.
Checking costly-to-compute invariant of data structure all the
time isn't meaningful after that class or set of classes has
been debugged and tested, but leaving more inexpensive asserts
in place is meaningful, because it can catch remaining logic
bugs.

Exactly. The most important assertions in production code are
generally pre-condition checks. Which are generally not too
expensive.

Of course, it also depends on the application. I've worked on
some very critical applications (locomotive brake systems, for
example), where we did verify the invariants after each
operation. If there's the slightest chance of an error, we want
to detect it immediately, and crash, so that the back-up can
take over. And this behavior is considered critical enough that
if it means paying more for a faster processor, you do it
anyway.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Roland Pibinger]

On Sat, 24 Nov 2007 10:26:45 -0800 (PST), James Kanze wrote:

>And I've never seen NDEBUG defined in the invocation line of the
compiler. Only an idiot would do something that stupid. You
define it only when you absolutely need to.

Visual C++ by default defines NDEBUG (/D "NDEBUG") for Release builds
"in the invocation line". I guess it makes no sense to continue that
discussion.

[James Kanze]

On Nov 24, 9:54 pm, [e-mail] (Roland Pibinger) wrote:

On Sat, 24 Nov 2007 10:26:45 -0800 (PST), James Kanze wrote:

And I've never seen NDEBUG defined in the invocation line of the
compiler. Only an idiot would do something that stupid. You
define it only when you absolutely need to.

Visual C++ by default defines NDEBUG (/D "NDEBUG") for Release builds
"in the invocation line".

You mean, no doubt, the IDE. VC++ (the command cl) doesn't
define much of anything by default; you need four or five
options just to get it to understand enough C++ to accept the
standard headers.

Of course, defaults don't mean anything. I've never seen a
compiler do anything useful "by default". (I use some 20 or 30
options with g++ or Sun CC. I suspect that I'd need just as
many if I were to do any serious work with VC++.)

And the Visual C++ is not designed for professional development,
but rather to support the hobby programmer.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]