Exception Misconceptions: Exceptions are better than return values

[dragan]

You hear this all the time: "Exceptions are better than return values". Or
the variations on that theme. This, of course, is a misconception when
stated as a generality (without context). A major problem attributed to
return values, no guarantee that the programmer will check the return value,
is a language design or implementation issue: the compiler should warn that
a return value is not being checked/assigned/whatever. With compiler return
value checking enforcement, analyses of when to use an exception mechanism
vs. a return code become much more practical/palatable.

 

[tanix]

You hear this all the time: "Exceptions are better than return values". Or
the variations on that theme. This, of course, is a misconception when
stated as a generality (without context). A major problem attributed to
return values, no guarantee that the programmer will check the return value,
is a language design or implementation issue: the compiler should warn that
a return value is not being checked/assigned/whatever. With compiler return
value checking enforcement, analyses of when to use an exception mechanism
vs. a return code become much more practical/palatable.

Well, to me, it is a fine mix.
With return values, you tend to get a convoluted spagetti code,
basically testing the result from any call, which is a royal waste
of everything.

Basically, when error condition occurs, exceptions work much better
because it does not much matter how deep on the stack some error
has occured. You can catch an exception on several levels deep
and produce some error message or to log things, and then even
rethrow the same or other exception so that higher level code
has a chance to possibly display a different, more general level
error message and decide how to handle the situation.

In plenty of cases the operation can be restarted or continued
from the next item on your processing list if that is possible.

But totally avoiding exceptions is probably the worst idea.
The same thing as totally relying on exception mechanism only.
It is a fine balance. The end result should be the most
robust operation of your code under ANY conditions whatsoever,
short of unplugging the power cable.

It is extremely difficult to write a robust code without
using exceptions.

 

[tanix]

Well, to me, it is a fine mix.
With return values, you tend to get a convoluted spagetti code,
basically testing the result from any call, which is a royal waste
of everything.

Basically, when error condition occurs, exceptions work much better
because it does not much matter how deep on the stack some error
has occured. You can catch an exception on several levels deep
and produce some error message or to log things, and then even
rethrow the same or other exception so that higher level code
has a chance to possibly display a different, more general level
error message and decide how to handle the situation.

In plenty of cases the operation can be restarted or continued
from the next item on your processing list if that is possible.

But totally avoiding exceptions is probably the worst idea.
The same thing as totally relying on exception mechanism only.
It is a fine balance. The end result should be the most
robust operation of your code under ANY conditions whatsoever,
short of unplugging the power cable.

It is extremely difficult to write a robust code without
using exceptions.

Come to think of it, you can review plenty of article on
exception by experts (defined loosely):

http://preciseinfo.
org/Convert/Articles_CPP/Exception_Experts/C++-VC-ATL-STL-Exception-Experts-in
dex.html

Those guys know what they are talking about.

Or code examples with exceptions:

http://preciseinfo.
org/Convert/Articles_CPP/Exception_Code/C++-VC-ATL-STL-Exception-Code-index.
html

 

[Bo Persson]

You hear this all the time: "Exceptions are better than return
values". Or the variations on that theme. This, of course, is a
misconception when stated as a generality (without context). A
major problem attributed to return values, no guarantee that the
programmer will check the return value, is a language design or
implementation issue: the compiler should warn that a return value
is not being checked/assigned/whatever. With compiler return value
checking enforcement, analyses of when to use an exception
mechanism vs. a return code become much more practical/palatable.

Right, so you always check the return value of printf to verify that
it produced the correct number of characters?

Exceptions are better when you (1) expect the function calls to almost
always succeed, and (2) can't do anything about a failure anyway (at
this level in the code).

If all you can do is check for an error in the return codes and pass
that back to your caller, the exception will do that for you.
Automation beats having to write manual checks everywhere.



Bo Persson

 

[James Kanze]

You hear this all the time: "Exceptions are better than return
values".

Where?

There's no silver bullet. For some types of errors, exceptions are
preferable. For others, return types are to be preferred. And there
are those where the only safe thing to do is to abort.

Or the variations on that theme. This, of course, is a misconception
when stated as a generality (without context). A major problem
attributed to return values, no guarantee that the programmer will
check the return value, is a language design or implementation issue:
the compiler should warn that a return value is not being
checked/assigned/whatever.

That would be logical, but for historical reasons, there are a lot of
functions in C (and thus callable from C++) which have return values
which interest no one. When was the last time you used the return
value
of strcpy, for example.

With compiler return value checking enforcement, analyses of when to
use an exception mechanism vs. a return code become much more
practical/palatable.

It's possible to design return code types such that they cause an
assertion failure if they're not checked. I've used them in some
applications. In this respect, there's probably even a slight
advantage
for return codes: to verify that an exception is correctly caught and
handled, you have to trigger it somehow---if the return code isn't
checked, the program will crash (assertion failure) even if there
wasn't
an error.

 

[dragan]

Well, to me, it is a fine mix.

Sarcasm? Because you go on to say:

With return values, you tend to get a convoluted spagetti code,
basically testing the result from any call, which is a royal waste
of everything.

Which is definitely a passionate statement against return codes and for
exceptions. You seem to consider them as interchangeable rather than
targeted-use tools.

Basically, when error condition occurs, exceptions work much better
because

See, you did it again. Given the way I worded the OP, I expected (or hoped)
that repliers would avoid the meaningless general statements.

[off-topic pedantic material snipped]

But totally avoiding exceptions is probably the worst idea. It is a fine
balance.

But apparently you seem to thing the opposite is not a bad idea (see your
own reply).

The same thing as totally relying on exception mechanism only.

Don't become a lawyer, because you'd suck at it: First you show your
enamoration with exceptions, and you try to sum-up as if you were
impartial/objective.

It is extremely difficult to write a robust code without
using exceptions.

That sounds like material for the next post in this series (Exception
Misconceptions)!

 

[dragan]

Right, so you always check the return value of printf to verify that
it produced the correct number of characters?

Are you asking if you would have to if compiler enforcement of return value
checking was active? If such a change for the better were to be made in the
standard, obviously there would be many changes for the better required to
be made to the standard library. Sounds like a good way to do "Spring
cleaning" (clean up that dirty old standard library and throw out the
useless and detrimental rugs).

Exceptions are better when you (1) expect the function calls to almost
always succeed, and (2) can't do anything about a failure anyway (at
this level in the code).

Good boy! You didn't make a passionate general statement about exceptions
vs. return codes. That said, your 1 and 2 are pretty lame as far as breadth
and depth go. It's a start though on the correct way of thinking about error
"handling".

If all you can do is check for an error in the return codes and pass
that back to your caller, the exception will do that for you.
Automation beats having to write manual checks everywhere.

Automation in the form of compiler enforcement of return value checking?
It could be a compiler command line switch. The legacy/progressive switch!

 

[dragan]

Where?

Anywhere C++ programmers are discussing error handling. Such as this
newsgroup.

There's no silver bullet.

That, of course, was implied by the OP. The "question" was "why?", not
"what?".

For some types of errors, exceptions are
preferable. For others, return types are to be preferred. And there
are those where the only safe thing to do is to abort.

Note that other responses to the OP confirm that the misconception is indeed
held by C++ programmers. That it was so easy to "fish for", implies it is
wide-spread and/or deeply-rooted.

That would be logical, but for historical reasons, there are a lot of
functions in C (and thus callable from C++) which have return values
which interest no one.

I threw the concept out there thinking maybe someone would give a good
reason why there was not such a thing as compiler enforcement of return
value checking. Apparently, there is no go reason why there isn't. Or not
apparent at this point anyway. It could be a compiler switch (?).

It's possible to design return code types such that they cause an
assertion failure if they're not checked.

It's impossible to make a "good" one though, as they have major
shortcomings, not the least of which is that they are just kludges for the
lack of compiler support for the functionality.

I've used them in some
applications. In this respect, there's probably even a slight
advantage
for return codes: to verify that an exception is correctly caught and
handled, you have to trigger it somehow---if the return code isn't
checked, the program will crash (assertion failure) even if there
wasn't
an error.

That's actually one of the shortcomings in disguise: It's a run time thing
instead of a compile time thing. Did I say "one"? It's two: the other one
"hidden" in your above passage is that the code MUST be exercised (tested)
through the code path or the crafted return object will not activate.

 

[Vladimir Jovic]

You hear this all the time: "Exceptions are better than return values". Or

Yes, I agree

[off-topic pedantic material snipped]

 

[dragan]

Yes, I agree

JK, you don't seem to be teaching these guys anything. (And just when you
wanted tenure? (?)).

 

[James Kanze]

JK, you don't seem to be teaching these guys anything. (And
just when you wanted tenure? (?)).

Teaching takes time. Just because some unknown beginner
expresses an opinion doesn't mean that it represents the
concensus of the experts.

There are, clearly, a number of programmers who think that
exceptions solve all problems. (There are also some who think
just the opposite.) Whether any of these can be counted among
the "experts" is another question. Historically, there are
trends, and they tend to swing: when exceptions first became
available (in major languages), there was a very strong swing
toward them, as exemplified in Java (which was initially defined
about that time). As time goes on, and we acquire experience
with the technique, the overshoot is amortized, and we tend to
oscilate to a more measured position. Back in the mid 1990's, I
was one of the few in the anti-exception camp (along with Herb
Sutter!), and had some more or less heated discussions with
people like Dave Abrahams, who strongly favored them. Today,
Dave and I have very similar positions, varying only in details
(and even more so, I think, in the way we expression them): he
definitely realizes that there are times when return codes (or
even other solutions, like that used in iostream or by IEEE
floating point) are appropriate, and I find exceptions very
useful in specific cases, and certainly wouldn't reject them out
of hand. I would guess that today, there is a consensus among
the experts, more or less around Dave's or my position.

 

[tanix]

Teaching takes time. Just because some unknown beginner
expresses an opinion doesn't mean that it represents the
concensus of the experts.

WHO are you talking about as "unknown beginner"?
Gennady Kalmykov, by ANY chance?

Wouuld you kindly expand on that?

There are, clearly, a number of programmers who think that
exceptions solve all problems.

Bullshit.
I know of not a single programmer that says that,
unless you are talking about some lunatic or cultist.

(There are also some who think
just the opposite.)

Too bad. They need their brains examined once in a while.

Whether any of these can be counted among
the "experts" is another question.

Uhu, and how do you define an "expert"?

Historically, there are
trends,

Scuze me, are you a politician or a programmer?

and they tend to swing:

You mean like a wind, blowing between your ears?

You are probably in the wrong business with this kind of language.
You should be a diplomat.

when exceptions first became
available (in major languages), there was a very strong swing
toward them,

Just like with anything else "new" that comes around.
Anything else is new under the sun?

as exemplified in Java

Sir, do you happen to have a problem with Java,
and what that problem might be?
Would you kindly spill out your position on that?

(which was initially defined
about that time). As time goes on, and we acquire experience
with the technique,

Which technique do you acuqure the exerience with?

the overshoot is amortized,

Meaning?
You are in the wrong business?
Are you a bookwarm, a book keeper or an accountant
that, for some strange reason, ended up polutting the lands
of ultimate beauty - the art of programming?

and we

Who is we?

Can't you learn to stand on YOUR own feet?
Or you foreven need to conspire with others?

Do you happen to have YOUR OWN opinion on ANYTHING?

tend to
oscilate to a more measured position.

Which is what?

Peddling the horshit by truckloads?

Sorry, sir, I am a software architect.
I don't take this kind of bullshit as something to even botther.
It simply takes up my time and creative energy on dealing with
lowest grade garbage and templates. I can not afford that.

Back in the mid 1990's,
Uhu.

I was one of the few in the anti-exception camp

You can not be THAT dumb, or could you?

All this "pro" and "anti" is a cult mentality.

(along with Herb
Sutter!),

Oh, I am impressed.

and had some more or less heated discussions with
people like Dave Abrahams,

On your knees, mortals!

who strongly favored them. Today,
Dave and I have very similar positions, varying only in details

such as?

Can you ever state anything in specifics that matter
in the scheme of things and change anything?

(and even more so, I think, in the way we expression them): he
definitely realizes that there are times when return codes

Definetely so. You can not run exception mechanism as your
progam logic. That is simply dumb if not outright extremist.

You can not use a gun to clean up your ears or even nose.
Everything has its own use and limitations.

(or
even other solutions, like that used in iostream or by IEEE
floating point) are appropriate, and I find exceptions very
useful in specific cases, and certainly wouldn't reject them out
of hand. I would guess that today, there is a consensus among
the experts,

Screw those "experts".
You you ARE presented in the expert section on programmer's
goldmine sites and you do have some brains, no question about it.
But what you write here is not of a sw expert position,
but of a cunning politician that says nothing that actually
means anything in reality.
What a pitty.

I am highly dissapointed.

more or less around Dave's or my position.

Oh, oh, oh, oh.

Who is Dave? A brother of Jesus Christ?
The inventor of the wheel?

And who are you, for that matter?

Are you on a standards committee by any chance?

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[dragan]

tanix wrote:

[what you wrote]

Wow. And I was worried about being "inflamatory" or "anti-social" or
something. I wouldn't hire him on my best day, but wo is me, I don't have
and never will have his ability/knowledge/etc.... that said, I know him, he
wants to live forever. Huh JK? Hey, maybe some of this Bobama money
floating around .... (I don't want it: call it "bad upbringing" or
whatever). Aren't weekends fun?'

Not to dillude: "thx" tannix. "you take the cake".

 

[tanix]

tanix wrote:

[what you wrote]

Wow. And I was worried about being "inflamatory" or "anti-social" or
something. I wouldn't hire him on my best day,

Well, when your rear end is on fire and you ARE a big gun in
the sw industry and you DO need some top notch guy to get your
job done, and you DO talk reality and not fiction,
then you look at things differently.

I don't recall a single job that was not done in the top notch
level, probably better than anything did that job for them
by far.

In fact, one of the opinions of one of my employers I remember
for many years now.

What he said something about me to someone else,
and they told me this is:

I NEVER EVER had someone doing such a good job.
I did not even believe such a thing is possible.
He does 2 times more work than anyone else I have ever hired
and the quality of his works is at least 2 times better,
and I can rely on what he did 10 times better
than ANYONE I ever had to hire.

Dig?

Do you have someting on YOUR reputation list that even comes
close to things like this?

Zo...

but wo is me,

True. At least you can keep things in proper perspective.

I don't have
and never will have his ability/knowledge/etc....

Not to worry. You will if you want it bad enough.
You see, for me it is my life. That is ALL I do.
To others, "it is just a job" thing.
See the difference?

that said, I know him, he
wants to live forever.

Not really. In fact I keep wondering about things like:
Isn't it enough? Or do you need more?
Haven't you lived 2 lives worth of stuff already?
Are you SO greedy that you need more?
What else do you expect to see or learn?

Dig?

Huh JK? Hey, maybe some of this Bobama money
floating around .... (I don't want it: call it "bad upbringing" or
whatever). Aren't weekends fun?'

:--}

Weekends are the MOST fun for me.
I enjoy weekends like nothing else besides sleep.

Weekends is when insanity takes a break.
I am greatful to christianity for those.

The phones stop ringing. You don't have to think where
to call, what stupid paper to send where, which stoopid
office you need to visit today and what other stoopid
things you need to do on working days.

So...

You can finally enjoy life on weekends.

Not to dillude: "thx" tannix. "you take the cake".

My pleasure.

:--}

Hope you enjoy the trip.
I don't happen to think that what is happening here on these
groups is something so signfifican that it matters much,
although I do get some useful info here and there.


--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[dragan]

tanix wrote:

[blather snipped]

I'm sorry I "acknowledged" you. (Can someone say, "created a monster"?). :/

 

[tanix]

tanix wrote:

[what you wrote]

Wow. And I was worried about being "inflamatory" or "anti-social" or
something. I wouldn't hire him on my best day, but wo is me, I don't have
and never will have his ability/knowledge/etc.... that said, I know him, he
wants to live forever. Huh JK? Hey, maybe some of this Bobama money
floating around .... (I don't want it: call it "bad upbringing" or
whatever). Aren't weekends fun?'

Not to dillude: "thx" tannix. "you take the cake".

I am glad you are so proud of your masterpice that you feel
it needs to be reposted, just to make sure such a grand piece of work
does not die in the shuffle.

:--}

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.