8 years of C++ Exception Handling

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.

Jul 22 '05 #5

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.

Jul 22 '05 #6

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.

Jul 22 '05 #7

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.

Jul 22 '05 #8

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?

Jul 22 '05 #9

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.

Jul 22 '05 #10

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.

Jul 22 '05 #11

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.

Jul 22 '05 #12

Jonathan Turkanis

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bu********@dispatch.concentric.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

Jul 22 '05 #13

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.

Jul 22 '05 #14

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> :=)

Jul 22 '05 #15

Gianni Mariani wrote:

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

Jul 22 '05 #16

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

Jul 22 '05 #17

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

Jul 22 '05 #18

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.

Jul 22 '05 #19

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.

Jul 22 '05 #20

Frank Puck

"lilburne" <li******@godzilla.com> wrote in message
news:bu************@ID-179504.news.uni-berlin.de...

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

Being aware of that certain statements may throw and writing code, which
does not ignore this fact.
Writing code that relies on the fact that it will only be executed if and
only if all previous statements have executed successfully.
Matching design philosophies including e.g.
* the notion of non-corrupting fail of an operation
* the notion that the enduser can expect to see a descriptive error
message,
which includes any system error message and maybe even stack-trace
information, e.g.:
Cannot parse input file "test.cpp", because of
Cannot start preprocessor, because of
maximum number of processes reached
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.

so you ignore that new may throw?
so you ignore that opening a file for writing may fail?
After that everything else failing is a bug/algorithm failure, and
outside the scope of legitimate handling by exceptions.

assertions are still useful

Jul 22 '05 #21

lilburne

Frank Puck wrote:

"lilburne" <li******@godzilla.com> wrote in message
news:bu************@ID-179504.news.uni-berlin.de...

So what do you consider post-C++-Exception-Handling?
Being aware of that certain statements may throw and writing code, which
does not ignore this fact.

I'd much rather not have any throws thanks you very much.
Writing code that relies on the fact that it will only be executed if and
only if all previous statements have executed successfully.
They damn well ought to have or the CPU needs replacing.
Matching design philosophies including e.g.
* the notion of non-corrupting fail of an operation

An operation unless it is permissible for the operation to
fail it is a coding/design bug.

* the notion that the enduser can expect to see a descriptive error
message,
which includes any system error message and maybe even stack-trace
information, e.g.:
Cannot parse input file "test.cpp", because of
Cannot start preprocessor, because of
maximum number of processes reached

Exceptions aren't a prerequisite for informative system
error messages.

What is the user going to do with a stack trace?

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.
so you ignore that new may throw?

Pretty much. If a calculation's memory requirements exceeds
the virtual address space, all the messing about in the
world ain't going obtain more. Now in our new handler we'll
release a few Mb which we reserved for such eventualities
and we'll set a flag to abort the current calculation, but
of course at this point no exception has fired.

so you ignore that opening a file for writing may fail?

We don't have any file IO that thows. At least not as far as
application code is concerned. If there is any throwing by
any particular OS it don't propagate outside of the wrapper
classes.

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

assertions are still useful

Indeed they are.

Jul 22 '05 #22

lilburne wrote:

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

This is probably the fundamental disagreement between our approaches.

Consider this:

{

BaseClass* base = someFunction....
DerivedClass* derived = std::dynamic_cast<DerivedClass>(base);

// I assume you use something like this for a 'debug' release
#ifdef DEBUG
assert(derived);
#endif // DEBUG

}

This code definitely helps developers make sure that after the cast,
derived is not NULL. Therefore developers are forced to add runtime
checking code. With properly designed exception code, you will not
execute code after an 'invalid' state, therefore simplifying code
construction.

For example if operation_<n> functions throw exceptions, the following
code will break if obj is in an 'invalid' state anywhere in the process.

Object obj;
operation_1_throws(obj);
operation_2_throws(obj);
operation_3_throws(obj);
operation_4_throws(obj);

This is much more readable an simple to encapsulate in try/catch than
the following code.

Object obj;

if(STATUS_OK != operation_1_ret(obj))
{
// failed here, handle this in some way
}
else if(STATUS_OK != operation_2_ret(obj))
{
// failed at operation_2, handle here
}
else if(STATUS_OK != operation_3_ret(obj))
{
// failed at operation_3, handle here
}
else if(STATUS_OK != operation_4_ret(obj))
{
// failed at operation_4, handle here
}

I do understand that there is a place for this type of code, all I'm
saying is that exceptions can be very useful and are, in some instances
(I'm pretty sure this topic has been brought to death in this or some
other forum...), better design solutions than return codes and even you
beloved assertions.

Cheers,

Jorge

Jul 22 '05 #23

Jonathan Turkanis

"Jorge Rivera" <jo*****@rochester.rr.com> wrote in message
news:Z4*******************@twister.nyroc.rr.com...

lilburne wrote:
Consider this:

{

BaseClass* base = someFunction....
DerivedClass* derived = std::dynamic_cast<DerivedClass>(base);

// I assume you use something like this for a 'debug' release
#ifdef DEBUG
assert(derived);
#endif // DEBUG

}

If you're willing to assume in release mode that base can be
static_cast'd to DerivedClass, then you should use static_cast. The
dynamic_cast, together with the assertion, can be used in debug mode.

Jonathan

Jul 22 '05 #24

Jonathan Turkanis wrote:

"Jorge Rivera" <jo*****@rochester.rr.com> wrote in message
news:Z4*******************@twister.nyroc.rr.com...
lilburne wrote:
Consider this:

{

BaseClass* base = someFunction....
DerivedClass* derived = std::dynamic_cast<DerivedClass>(base);

// I assume you use something like this for a 'debug' release
#ifdef DEBUG
assert(derived);
#endif // DEBUG

}

If you're willing to assume in release mode that base can be
static_cast'd to DerivedClass, then you should use static_cast. The
dynamic_cast, together with the assertion, can be used in debug mode.

I guess you are an MSVC++ developer only, right? There is no definition
in C++ about 'debug' or 'release' versions. Whatever optimizations
Microsoft uses does not change what standard behavior is. The use of
dynamic_cast over static_cast is a design decision, nor a build decision.

I do appreciate the comment, as I did not know this about MSVC++ (if you
use a different compiler, let me know).

Jorge L.

Jonathan

Jul 22 '05 #25

tom_usenet

On Sat, 24 Jan 2004 21:44:57 GMT, Jorge Rivera
<jo*****@rochester.rr.com> wrote:

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.

You can create return values that have to be checked.

template <class T>
struct ret_value
{
ret_value(T const& value)
:m_value(value), m_checked(false) {}

~ret_value()
{
if (!m_checked)
std::terminate();
}

T& get()
{
m_checked = true;
return m_value;
}

operator T&()
{
return get();
}

private:
T m_value;
bool m_checked;
};

or similar. Exceptions aren't there to force you to handle errors,
they're there to allow you to handle an errors at the point that you
have enough information available to handle the error without manually
returning it up the call stack.

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

Jul 22 '05 #26

tom_usenet wrote:

On Sat, 24 Jan 2004 21:44:57 GMT, Jorge Rivera
<jo*****@rochester.rr.com> wrote:

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.

You can create return values that have to be checked.

template <class T>
struct ret_value
{
ret_value(T const& value)
:m_value(value), m_checked(false) {}

~ret_value()
{
if (!m_checked)
std::terminate();
}

T& get()
{
m_checked = true;
return m_value;
}

operator T&()
{
return get();
}

private:
T m_value;
bool m_checked;
};

or similar. Exceptions aren't there to force you to handle errors,
they're there to allow you to handle an errors at the point that you
have enough information available to handle the error without manually
returning it up the call stack.

Even if this was the original intention of exceptions, that is the way I
like using them. Although the approach you present serves the purpose
of making sure that clients check status variables, there are design
disadvantages to this approach (OK, that was a stupid comment, as that
applies to everything in this discussion....).

I hadn't thought of this approach though, and it appears very useful.
In the future I may do more things like this to reduce dependency on
exception handling mechanisms. Thanks,

Jorge L.
Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

Jul 22 '05 #27

lilburne

Jorge Rivera wrote:

lilburne wrote:

You'd probably hate mine too. Minimal runtime checking but heavily
laced with assertions. Violate a precondition and in a debug run -
kerboom.
This is probably the fundamental disagreement between our approaches.

Consider this:

{

BaseClass* base = someFunction....
DerivedClass* derived = std::dynamic_cast<DerivedClass>(base);

// I assume you use something like this for a 'debug' release
#ifdef DEBUG
assert(derived);
#endif // DEBUG

}

This code definitely helps developers make sure that after the cast,
derived is not NULL. Therefore developers are forced to add runtime
checking code. With properly designed exception code, you will not
execute code after an 'invalid' state, therefore simplifying code
construction.

Yes this is the fundamental difference.

We would say that if someFunction is returning BaseClass* then the
calling code should handle a BaseClass. Dynamic casting might help to
select efficient methods for processing different types of DerivedClass,
but it is a bug not to handle the general case too.

Alternatively it might be a post-condition that someFunction always
returns DerivedClass, if someFunction subsequently changes so that it
returns other things that is an API change and I don't think that
calling code should be testing for API changes in the code it calls.
Where would it end?

If the assumption is that someFunction always returns a DerivedClass
then the assert is sufficient (BTW no conditional required).

The technical problem we have with exceptions is the overhead of stack
unwinding. A simple test I wrote a month or so ago had gcc 3.3 5 times
slower in the presence of a try, throw, catch than an assert. This seems
to be a particular problem with 3.3 as our previous tests have only
shown a 20% performance degradation. Performance is a critical factor to
our customers as calculations can take several hours and even days in
some cases, and whilst we tend to be the fastest in the industry taking
a hit for something that should never occur seems to be too much to ask.
I'd rather that 20% was spent on improving surface quality then trapping
bugs at runtime.

A phillosophical problem we have is that it assumes that the calling
code is going to catch the exception. But if the caller couldn't be
bothered to ensure that the arguments being passed were such that the
called code could proceed then it is unlikely the caller will bother to
catch an exception either. Probably somewhere up in the main loop there
is a catch(...) but this seems like an aweful cop-out.

For example if operation_<n> functions throw exceptions, the following
code will break if obj is in an 'invalid' state anywhere in the process.

Object obj;
operation_1_throws(obj);
operation_2_throws(obj);
operation_3_throws(obj);
operation_4_throws(obj);
Well again we'd say that a precondition of each of these functions is
that 'obj' is not invalid.

void operation_1(Object &obj) {
assert(obj.invalid() == false);
// perform operation1
}
perhaps our applications are such that we have full control over the
objects we create, outside of I/O our objects don't become invalid.

We certainly wouldn't expect that a consequence of calling operation_1
would be to cause a perfectly good 'obj' to become invalid. Perhaps
operation_1 initializes 'obj'? In which case we wouldn't expect
operation_2 to cause a perfectly good 'obj' to be come invalid.

I don't see the additional clarity of:

try {
Object obj;
operation_1_throws(obj);
operation_2_throws(obj);
operation_3_throws(obj);
operation_4_throws(obj);
}
catch (...) {
}

over

Object obj;
if (MY_OK == operation_1(obj))
operation_2(obj);
operation_3(obj);
operation_4(obj);
} else {
}

(I'm pretty sure this topic has been brought to death in this or some
other forum...), better design solutions than return codes and even you
beloved assertions.

Better design solutions are always preferable.

Jul 22 '05 #28