8 years of C++ Exception Handling

[Frank Puck]

Meanwhile there are at least 8 years that compilers exist,
which provide a working implementation of C++ Exception Handling.
Has anything changed meanwhile?
From my point of view nothing has changed
-- people are still using a coding style, which I call
pre-C++-Exception-Handling.
Is this different in your experience?
What is your experience regarding this subject?
I think that a C++ IOstream lib, which is by standard free of exceptions
certainly did not help here.

 

[Jacques Labuschagne]

Meanwhile there are at least 8 years that compilers exist,
which provide a working implementation of C++ Exception Handling.
Has anything changed meanwhile?
From my point of view nothing has changed
-- people are still using a coding style, which I call
pre-C++-Exception-Handling.

Some people. Others use whatever is appropriate in a particular
situation.

Is this different in your experience?

Yes. I've seen plenty of code that uses exceptions where appropriate,
often in conjunction with older error-handling strategies.

What is your experience regarding this subject?
I think that a C++ IOstream lib, which is by standard free of exceptions
certainly did not help here.

Exceptions are not intented to be the only error-handling mechanism.
I would also suspect that the minimal use of exceptions probably
hastened the adoption of the standard libraries by compilers who
weren't capable of exceptions, back in the dark ages.

My $0.02,
Jacques

 

[Jonathan Turkanis]

Meanwhile there are at least 8 years that compilers exist,
which provide a working implementation of C++ Exception Handling.
Has anything changed meanwhile?
From my point of view nothing has changed
-- people are still using a coding style, which I call
pre-C++-Exception-Handling.
Is this different in your experience?
What is your experience regarding this subject?
I think that a C++ IOstream lib, which is by standard free of exceptions
certainly did not help here.

Exceptions are useful when code knows how to detect errors but not how
to handle them. A good percentage of the time, code performing i/o
knows exactly how to handle errors ( std::cout << "I said input a
number, stupid!\n" ) and having to wrap each bit of code int try-catch
blocks would be extremely inconvenient. When you really don't know how
to handle errors, you can enable exceptions.

Exceptions were disabled by default for backward compatibility, as you
probably know. I find that the default behavior is usually
appropriate, however.

Jonathan

 

[lilburne]

Meanwhile there are at least 8 years that compilers exist,
which provide a working implementation of C++ Exception Handling.
Has anything changed meanwhile?
From my point of view nothing has changed
-- people are still using a coding style, which I call
pre-C++-Exception-Handling.

So what do you consider post-C++-Exception-Handling?

Is this different in your experience?
What is your experience regarding this subject?

I don't tolerate exceptions other than from data input from files or
other external data sources. Once data has been accepted, there should
be no exceptional conditions, and data created internally should not
cause an exceptional condition.

After that everything else failing is a bug/algorithm failure, and
outside the scope of legitimate handling by exceptions.

 

[Jorge Rivera]

So what do you consider post-C++-Exception-Handling?


I don't tolerate exceptions other than from data input from files or
other external data sources. Once data has been accepted, there should
be no exceptional conditions, and data created internally should not
cause an exceptional condition.

After that everything else failing is a bug/algorithm failure, and
outside the scope of legitimate handling by exceptions.

I disagree to this last statement. You can use exceptions to avoid (or
try very hard at least) people from ignoring errors. I mean, how often
have you seen code or written that ignore return status? You just can't
do that with exceptions, or you have to pay for it...

Exceptions, if designed and used properly, can help in producing more
robust code. Let { if(ret == -1) } code for C programmers....

Jorge L.

 

[E. Robert Tisdale]

Meanwhile there are at least 8 years that compilers exist,
which provide a working implementation of C++ Exception Handling.
Has anything changed meanwhile?
From my point of view nothing has changed
-- people are still using a coding style,
which I call pre-C++-Exception-Handling.
Is this different in your experience?
What is your experience regarding this subject?
I think that a C++ IOstream lib,
which is by standard free of exceptions
certainly did not help here.

I don't think that you understand exception handling
or even what an exception is.

My guess is that you *throw* exceptions from void functions,
that you *throw* exceptions when you detect programming errors,
that you write code to detect exceptions that should never occur and
that you *throw* exceptions even when the exception could be handled
in the scope where it was first detected.

 

[Gianni Mariani]

I disagree to this last statement. You can use exceptions to avoid (or
try very hard at least) people from ignoring errors. I mean, how often
have you seen code or written that ignore return status? You just can't
do that with exceptions, or you have to pay for it...

Exceptions, if designed and used properly, can help in producing more
robust code. Let { if(ret == -1) } code for C programmers....

My experience is the opposite to this. I find that (lazy) programmers
rely on exception handlers above them in the stack frame to perform
unknown magic.

 

[Jorge Rivera]

My experience is the opposite to this. I find that (lazy) programmers
rely on exception handlers above them in the stack frame to perform
unknown magic.

Any language feature can be abused. I still prefer them over returning
error code values.

I do acknowledge that status codes are appropriate in some cases, I am
only opposed to the abuse of them, and the likelihood of lazy
programmers ignoring them.

Cheers,

Jorge L.

 

[E. Robert Tisdale]

Any language feature can be abused.
I still prefer them over returning error code values.

Why return an error code?
Why not return a complete *exception* object
which includes *all* of the information required
to handle the exception in an enclosing scope?

 

[Gianni Mariani]

I don't think that you understand exception handling
or even what an exception is.

My guess is that you *throw* exceptions from void functions,
that you *throw* exceptions when you detect programming errors,
that you write code to detect exceptions that should never occur and
that you *throw* exceptions even when the exception could be handled
in the scope where it was first detected.

What you wrote is ambiguous. Are the points you wrote above
reccomendations or attempt at ESP ? There are a things you said there
that throw alarm bells.

 

[Gianni Mariani]

Why return an error code?
Why not return a complete *exception* object
which includes *all* of the information required
to handle the exception in an enclosing scope?

To have an intelligent discussion here, I think we need to categorize
the different conditions that are candidates for management by exception
and then compare them to alternative ways that they can be handled.

.... I'll let someone else take a crack at it, I'm sleepy.

 

[lilburne]

I disagree to this last statement. You can use exceptions to avoid (or
try very hard at least) people from ignoring errors. I mean, how often
have you seen code or written that ignore return status? You just can't
do that with exceptions, or you have to pay for it...

Exceptions, if designed and used properly, can help in producing more
robust code. Let { if(ret == -1) } code for C programmers....

What is an error? Other than user input problems, hardware failure, etc
I wouldn't accept that there are any errors that aren't bugs.

In your example how do *you* know that failure 'if(ret == -1)' wasn't what
I was coding for? By throwing an exception *you* have dictated that *my*
code
does its processing inside a catch block, which just seems plain odd.

Additionally even if I write *my* code such that your code never throws an
exception *you* still force me to pay the overhead of stack unwinding.

 

[Jonathan Turkanis]

E. Robert Tisdale wrote:

What you wrote is ambiguous. Are the points you wrote above
reccomendations or attempt at ESP ? There are a things you said there
that throw alarm bells.

Shouldn't that be *throw* alarm bells? ;-)

Jonathan

 

[E. Robert Tisdale]

What you wrote is ambiguous.
Are the points you wrote above recommendations or attempt at ESP?
There are a things you said there that *throw* alarm bells.

I can't help you with the ringing in your ears.
You need to see your doctor.

Good C++ programmers know what I'm talking about and
I'm sure that they would be happy to answer
any specific questions that you might have about
when and how to use the C++ exception handling mechanism.

 

[Gianni Mariani]

I can't help you with the ringing in your ears.
You need to see your doctor.

Good C++ programmers know what I'm talking about and
I'm sure that they would be happy to answer
any specific questions that you might have about
when and how to use the C++ exception handling mechanism.

I think I stated my question clearly - you posed your position
ambigously - are your points reccomendations or are they an attempt to
charaterize what the previous poster was thinking. You can answer the
question by either stating your position in the first person or you can
state them as positive or negative attribues to good programming.

I'm not sure, but the tone I read from your response is one of
superiority and condescension which should be kind of an embarasment for
you since you clearly assumed a position which is probably is likely to
alienate 50% of "Good C++" progammers. Asserting you are a good
programmer does not prove the case.

C++ exceptions are still one of the areas where there is lack of clear
concensus on the appropriate use. While I agree that the feauture is
useful, I think they lead to far more issues than they solve, and some
of the reasons you have stated in your earlier post.

Forgive me, but I don't know that you're as good as you assert(you are)
and so I am just not too sure you know which side of the points you >>
raise you fall on. catch( the drift ) ?

<below the belt> ... did you write exceptions for the Spirit rover ?
</below the belt> :=)

 

[E. Robert Tisdale]

I find that (lazy) programmers rely on exception handlers above them

 

[Gianni Mariani]

I'm still working on my mind and tarrot reading. I'll get back to you
when I know what you're talking about.

BTW - I'd look at the exception handlers on that Spirit rover, you've
got an unhandled exception ...

 

[Rolf Magnus]

I'm still working on my mind and tarrot reading. I'll get back to you
when I know what you're talking about.

It probably _does_ take a rocket scientist to understand what he's
talking about.

 

[Jorge Rivera]

What is an error? Other than user input problems, hardware failure, etc
I wouldn't accept that there are any errors that aren't bugs.

That's your definition of an error, and I guess I have the freedom of
designing my classes to define error as something different, right?

In your example how do *you* know that failure 'if(ret == -1)' wasn't what
I was coding for? By throwing an exception *you* have dictated that *my*
code
does its processing inside a catch block, which just seems plain odd.

But that's exactly what I want. I do not allow you to continue without
checking for the error. You CAN NOT ignore it, even if it causes you
the paing of processing the error in a catch block, it is better (and
ths is, of course, just my perspective and programming approach) than
just allowing you to ignore the return code.

Therefore, my design forces you to use my code in a way I feel confident
in saying that you can rely on.

Additionally even if I write *my* code such that your code never throws an
exception *you* still force me to pay the overhead of stack unwinding.

Well, I guess you would just hate my libraries, which is of course,
perfectly reasonable.

Thanks for the comments though, I will keep all that in mind for future
designs,

Jorge L.

 

[lilburne]

But that's exactly what I want. I do not allow you to continue without
checking for the error. You CAN NOT ignore it, even if it causes you
the paing of processing the error in a catch block, it is better (and
ths is, of course, just my perspective and programming approach) than
just allowing you to ignore the return code.

Therefore, my design forces you to use my code in a way I feel confident
in saying that you can rely on.

Well I still don't know what you mean by an error, but you
could probably achieve the same by assertions. That way you
force me to fix my code in debug, and I don't pay for the
checks in release.

Well, I guess you would just hate my libraries, which is of course,
perfectly reasonable.

You'd probably hate mine too. Minimal runtime checking but
heavily laced with assertions. Violate a precondition and in
a debug run - kerboom.