Understanding Assert and Exceptions

[mailforpr]

Sometimes, I can't think of any good reason why I should have the
program's logic thrown an exception. Except for catching the exception
and printing "Uh, oh" to the screen. I also think that in most cases
there's simply no way to handle an exception properly, because what can
one do about an integer overflow? Reassign values? Restart the program?
The problem will still be existing. I think that an integer overflow is
not an exception, but sluttish programming.

Now I think printing a message "There's a bug - I'm so sorry" is much
better than some bizarre error message provided by the operating
system. Kind of better than assert, which disappears when I compile the
release version and causes the bizarre error message if the bug's still
there.

My conclusion: throwing an exception is still better than assert, for
you can always print a user friendly message to the screen. You could
even provide a dialog or something and ask the user to write down the
steps that caused the bug in a text field.

I saw some guy named "lilburne" say "Use always assert, unless you have
no other choice, but even then consider the exception to be a design
flaw to be eliminated."

Somehow, I agree. After all, if you check for an error condition, then
in some sense you expect it to happen and it is no exception
whatsoever.

Now, if you happen to have any exceptional situations and you deside to
throw an exception, this is more an excuse for poor programming, I
think. Again, what can one do about an integer overflow? Or a wrong
static_cast?

Knowing that something went wrong seems to be the only good point about
exceptions to me anyway. But then again, I am all for assert, as they
don't throw an excuse to the end user. But this has to be done, anyhow.
What do you think?

[Phlip]

mlimber wrote:

Sure. But my point was that there are a good number of circumstances
where unit tests are simply not feasible (embedded systems is one,
legacy code with no existing unit tests is another) but where
exceptions and assertions can and should still be used.

I suspect a mis-alignment here.

I meant that tests, exceptions, and assertions are a three-legged stool. I
think you mean that tests can absolve the need for some of them. Maybe. You
are correct that's the fuzzier topic!

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Duane Hebert]

"red floyd" <no*****@here.d udewrote in message
news:YU******** *******@newssvr 14.news.prodigy .com...

Duane Hebert wrote:

>"Julián Albo" <JU********@ter ra.eswrote in message
news:45******* *@x-privat.org...

>>Duane Hebert wrote:

And with exception you only need:

perform_transac tion ();

And the error handling does not get mixed with the normal flow of
execution.

I don't get that. If you don't catch the exception
what is going to happen? At some point you
have to catch it and deal with the error anyway.

If an exception is uncaught, eventually terminate() is called, causing
your program to drop dead.

Well that's my point. Saying that with an exception
you only need:

perform_transac tion();

is only true if it's OK for your program to
terminate. Seems hard to grasp how failure
to perform a transaction should do that.

Normally you're going to have
to write a try/catch block around it. In that
case, it's no "cleaner" than the if block IMO.

[Duane Hebert]

"Julián Albo" <JU********@ter ra.eswrote in message
news:45******** @x-privat.org...

Duane Hebert wrote:

>>And with exception you only need:

perform_transac tion ();

And the error handling does not get mixed with the normal flow of
execution.

I don't get that. If you don't catch the exception
what is going to happen? At some point you
have to catch it and deal with the error anyway.

The point is that at some point I, or some other programmer that use the
function, can catch the exception. Or just let the program terminate, if
it's a simple command line tool used for people that knows how is written.

And so then the exception example is not
so elegant. I would still have it return
a bool. If you want to bail at that point,
you can always let the caller throw if there's
no other way out. But how can you know that
from inside of perform_transac tion()?
I don't think embracing exceptions
for error indication is the correct thing to do.
Feel free to have your own opinion <g>

[Julián Albo]

Duane Hebert wrote:

>The point is that at some point I, or some other programmer that use the
function, can catch the exception. Or just let the program terminate, if
it's a simple command line tool used for people that knows how is
written.

And so then the exception example is not so elegant.

Don't see the point.

I would still have it return a bool.

Just do it. This is not a "Always do it that way" thing.

I don't think embracing exceptions for error indication is the correct
thing to do.

I don't think so. I also don't think that return error codes is "the
correct" thing. There are no one only correct way.

--
Salu2

[Gavin Deane]

Duane Hebert wrote:

"red floyd" <no*****@here.d udewrote in message
news:YU******** *******@newssvr 14.news.prodigy .com...

Duane Hebert wrote:

"Julián Albo" <JU********@ter ra.eswrote in message
news:45******** @x-privat.org...
Duane Hebert wrote:

And with exception you only need:

perform_transac tion ();

And the error handling does not get mixed with the normal flow of
execution.

I don't get that. If you don't catch the exception
what is going to happen? At some point you
have to catch it and deal with the error anyway.

If an exception is uncaught, eventually terminate() is called, causing
your program to drop dead.

Well that's my point. Saying that with an exception
you only need:

perform_transac tion();

is only true if it's OK for your program to
terminate.

No. It's also true if the error handling code is at some level above
the code that calls perform_transac tion.

Seems hard to grasp how failure
to perform a transaction should do that.

Normally you're going to have
to write a try/catch block around it.

Yes, at some level, but not necessarily the same level as the call to
perform_transac tion.

In that
case, it's no "cleaner" than the if block IMO.

A try-catch block is only no cleaner than an if-else block if the error
handling happens at the same level as the call to perform_transac tion.
If the error handling happens further up the call stack then, with an
exception, all the intermediate layers can ignore the failure and
remain unchanged. Whereas, if perform_transac tion returns an error code
or flag, every intermediate layer must have a return code and maybe an
if-else block added just to propogate the error state up to the level
that needs to know about it, which is definitely less clean than the
exception solution.

Gavin Deane

[mlimber]

Gavin Deane wrote:

Duane Hebert wrote:

In that
case, it's no "cleaner" than the if block IMO.

A try-catch block is only no cleaner than an if-else block if the error
handling happens at the same level as the call to perform_transac tion.
If the error handling happens further up the call stack then, with an
exception, all the intermediate layers can ignore the failure and
remain unchanged. Whereas, if perform_transac tion returns an error code
or flag, every intermediate layer must have a return code and maybe an
if-else block added just to propogate the error state up to the level
that needs to know about it, which is definitely less clean than the
exception solution.

In other words:

int f1();
int f2();
int f3();
int f4();
int f5();
int f6();

int g1()
{
int rc = f1();
if( 0 != rc )
{
return rc;
}

rc = f2();
if( 0 != rc )
{
return rc;
}

rc = f3();
if( 0 != rc )
{
return rc;
}
return 0;
}

int g2()
{
int rc = f4();
if( 0 != rc )
{
return rc;
}

rc = f5();
if( 0 != rc )
{
return rc;
}

rc = f6();
if( 0 != rc )
{
return rc;
}
return 0;
}

int h()
{
int rc = g1();
if( 0 != rc )
{
// Do some error handling
return rc;
}

rc = g2();
if( 0 != rc )
{
// Do some error handling
return rc;
}
return 0;
}

Vs.

void f1();
void f2();
void f3();
void f4();
void f5();
void f6();

void g1()
{
f1();
f2();
f3();
}

void g2()
{
f4();
f5();
f6();
}

void h()
{
try
{
g1();
g2();
}
catch( const std::exception& e ) // and/or custom exception classes
{
// Do some error handling
}
}

While both leave the error handling proper to a higher level [viz., in
h()], the second version represents the program flow much more clearly
thanks to exceptions.

Cheers! --M

[mlimber]

Phlip wrote:

mlimber wrote:

Sure. But my point was that there are a good number of circumstances
where unit tests are simply not feasible (embedded systems is one,
legacy code with no existing unit tests is another) but where
exceptions and assertions can and should still be used.

I suspect a mis-alignment here.

I meant that tests, exceptions, and assertions are a three-legged stool. I
think you mean that tests can absolve the need for some of them. Maybe. You
are correct that's the fuzzier topic!

It sounded to me like you were saying that using assertions and
exceptions is pointless (like a two-legged stool) unless there are unit
tests to back them up and test them out thoroughly. I'm saying that
sometimes it is not practical to build such a unit test suite but that
even in those case, exceptions and assertions can still be of great
utility.

Cheers! --M

[mlimber]

ma*******@googl email.com wrote:

My conclusion: throwing an exception is still better than assert, for
you can always print a user friendly message to the screen.
[...]
Now, if you happen to have any exceptional situations and you deside to
throw an exception, this is more an excuse for poor programming, I
think. Again, what can one do about an integer overflow? Or a wrong
static_cast?
[...]
What do you think?

Sutter and Alexandrescu in _C++ Coding Standards_ address error
handling policy in more detail than we will likely do here (but, for my
taste, even more detail than theirs would be useful!). Some key
summaries are:

Item 68: Assert liberally to document internal assumptions and
invariants. Be assertive! use assert or an equivalent liberally to
document assumptions internal to a module (i.e., where the caller and
callee are maintained by the same person or team) that must always be
true and otherwise represent programming errors (e.g., violations of a
function's postconditions detected by the caller of the function).

Item 70: Distinguish between errors and non-errors. A breach of
contract is an error: A function is a unit of work. Thus, failures
should be viewed as errors or otherwise based on their impact on
functions. Within a function f, a failure is an error if and only if it
violates one of f's preconditions or prevents f from meeting any of its
callees' preconditions, achieving any of f's own postconditions, or
reestablishing any invariant that f shares responsibility for
maintaining. In particular here we exclude internal programming errors
(i.e., where the caller and callee are the responsibility of the same
person or team, such as inside a module), which are a separate category
normally dealt with using assertions (see Item 68).

Item 72: Prefer to use exceptions to report errors. When harmed, take
excpetion: Prefer using exceptions over error codes to report errors.
Use status codes (e.g., return codes, errno) for errors when exceptions
cannot be used (see Item 62), and for conditions that are not errors
[e.g., when a key is not found in a std::map --M]. Use other methods,
such as graceful or ungraceful termination, when recovery is impossible
or not required.

Cheers! --M

[Phlip]

mlimber wrote:

It sounded to me like you were saying that using assertions and
exceptions is pointless (like a two-legged stool) unless there are unit
tests to back them up and test them out thoroughly. I'm saying that
sometimes it is not practical to build such a unit test suite but that
even in those case, exceptions and assertions can still be of great
utility.

Always try to automate any test you can think of. Such tests reduce the time
you'll spend debugging, so they free up development time for more valuable
activities.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[mlimber]

Phlip wrote:

mlimber wrote:

It sounded to me like you were saying that using assertions and
exceptions is pointless (like a two-legged stool) unless there are unit
tests to back them up and test them out thoroughly. I'm saying that
sometimes it is not practical to build such a unit test suite but that
even in those case, exceptions and assertions can still be of great
utility.

Always try to automate any test you can think of. Such tests reduce the time
you'll spend debugging, so they free up development time for more valuable
activities.

Of course, but sometimes that just isn't practical. That's my point.
(This is no longer a C++ discussion, by the way, but a software
engineering one.)

Cheers! --M