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]

Frank Puck wrote:

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]

"Frank Puck" <ne***********@ sbcglobal.net> wrote in message
news:wu******** ********@newssv r29.news.prodig y.com...

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]

Frank Puck wrote:

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]

lilburne wrote:

Frank Puck wrote:

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.

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.

[Gianni Mariani]

Jorge Rivera wrote:

lilburne wrote:

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

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]

Gianni Mariani wrote:

Jorge Rivera wrote:

lilburne wrote:

Frank Puck wrote:

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]

Frank Puck wrote:

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.

[E. Robert Tisdale]

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?

[Gianni Mariani]

E. Robert Tisdale wrote:

Frank Puck wrote:

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.

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.