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.

[Gianni Mariani]

E. Robert Tisdale wrote:

Jorge Rivera wrote:

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?

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]

Jorge Rivera wrote:

lilburne wrote:

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....

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]

"Gianni Mariani" <gi*******@mari ani.ws> wrote in message
news:bu******** @dispatch.conce ntric.net...

E. Robert Tisdale wrote:

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.

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

Jonathan

[E. Robert Tisdale]

Gianni Mariani wrote:

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]

E. Robert Tisdale wrote:

Gianni Mariani wrote:

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.

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]

Gianni Mariani wrote:

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

in the stack frame to perform unknown magic.

[Gianni Mariani]

E. Robert Tisdale wrote:

Gianni Mariani wrote:

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

> > in the stack frame to perform unknown magic.

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]

Gianni Mariani wrote:

E. Robert Tisdale wrote:

Gianni Mariani wrote:

> I find that (lazy) programmers rely on exception handlers above
> them
> > in the stack frame to perform unknown magic.

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]

lilburne wrote:

Jorge Rivera wrote:

lilburne wrote:

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

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]

Jorge Rivera wrote:

lilburne wrote:

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.

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.

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.

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