Arguments *Against* Exception Use

[Scott Brady Drummonds]

Hi, all,

I just got out of a meeting with a team of software developers that I
recently joined as they are staffing to create a medium-sized project
(potentially all of which will be written in C++). From my experience and
readings, I've come to this group indoctrinated to use exceptions for error
handling. The experience in this group that leads them to believe that
exceptions should only be used where severe runtime errors require program
termination is mainly based on the notion that the performance impact of
exceptions is prohibitive.

Besides the Meyers books and my trusty copy of "C++ FAQs", I'm going on my
intuition based on years of experience. Am I over-indoctrinated in the use
of exceptions? Are there some warnings that I'm not heeding? Can
exceptions impact performance to the degree that my coworkers claim? I'd
like to hear some anti-exception thoughts, if they exist.

Thanks!
Scott

--
Remove .nospam from my e-mail address to mail me.

http://www.e-scott.net

[Alf P. Steinbach]

* Scott Brady Drummonds:

Hi, all,

I just got out of a meeting with a team of software developers that I
recently joined as they are staffing to create a medium-sized project
(potentially all of which will be written in C++). From my experience and
readings, I've come to this group indoctrinated to use exceptions for error
handling. The experience in this group that leads them to believe that
exceptions should only be used where severe runtime errors require program
termination is mainly based on the notion that the performance impact of
exceptions is prohibitive.

Besides the Meyers books and my trusty copy of "C++ FAQs", I'm going on my
intuition based on years of experience. Am I over-indoctrinated in the use
of exceptions? Are there some warnings that I'm not heeding? Can
exceptions impact performance to the degree that my coworkers claim? I'd
like to hear some anti-exception thoughts, if they exist.

Context?

If coding for a micro-controller or, say, an OS kernel: yes, C++ exceptions
are probably UnGood.

Otherwise: no, C++ exceptions are Good.

But regardless of context, if the question is really on the table, then one
reasonable way to proceed could be to measure typical code. Things to
measure: time needed to complete correctly functioning code, time needed to do
some modification of the code, execution time in ordinary usage.

I bet those software developers think raw pointers and Hungarian notation (not
to mention a "repository" to copy code snippets from!) are nice ideas, too...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ali Çehreli]

"Scott Brady Drummonds" <sc**********************@intel.com> wrote in
message news:cm**********@news01.intel.com...

I'd like to hear some anti-exception thoughts, if they exist.

You may want to read Herb Sutter's article named When and How to Use
Exceptions, in the August 2004 issue of the C/C++ Users Journal.

If you decide to use exceptions in the project, the section dedicated to
exceptions in the book Exceptional C++ by Herb Sutter will be
exceptionally useful :) There are sequels to this book, which should be
helpful too, but I haven't read them yet:

http://www.gotw.ca/publications/index.htm

Ali

[Cy Edmunds]

"Scott Brady Drummonds" <sc**********************@intel.com> wrote in
message news:cm**********@news01.intel.com...

Hi, all,

I just got out of a meeting with a team of software developers that I
recently joined as they are staffing to create a medium-sized project
(potentially all of which will be written in C++). From my experience and
readings, I've come to this group indoctrinated to use exceptions for
error
handling. The experience in this group that leads them to believe that
exceptions should only be used where severe runtime errors require program
termination is mainly based on the notion that the performance impact of
exceptions is prohibitive.

Besides the Meyers books and my trusty copy of "C++ FAQs", I'm going on my
intuition based on years of experience. Am I over-indoctrinated in the
use
of exceptions? Are there some warnings that I'm not heeding? Can
exceptions impact performance to the degree that my coworkers claim? I'd
like to hear some anti-exception thoughts, if they exist.

Thanks!
Scott

--
Remove .nospam from my e-mail address to mail me.

http://www.e-scott.net

I never could figure out how use of exceptions could cause such big run time
errors. If you use them properly as error handlers rather than control
structures they won't be invoked often enough to run up much execution time.
And if you avoid exception specifications (which are basically useless
anyway) they don't have much overhead at all.

--
Cy
http://home.rochester.rr.com/cyhome/

[E. Robert Tisdale]

Scott Brady Drummonds wrote:

I just got out of a meeting with a team of software developers
that I recently joined as they are staffing to create
a medium-sized project (potentially all of which will be written in C++).
From my experience and readings,
I've come to this group indoctrinated to use exceptions for error handling.
The experience in this group that leads them to believe that
exceptions should only be used
where severe runtime errors require program termination
is mainly based on the notion that
the performance impact of exceptions is prohibitive. Besides the Meyers books and my trusty copy of "C++ FAQs",
I'm going on my intuition based on years of experience.
Am I over-indoctrinated in the use of exceptions?
Are there some warnings that I'm not heeding?
Can exceptions impact performance to the degree that my coworkers claim?
I'd like to hear some anti-exception thoughts, if they exist.

Your question is very vague.

No, the exception handling mechanism should *not* be used
for normal flow control. It should only be used
for expected but unpredictable and unpreventable events
that are rare *exceptions* to the normal result.
The exception handling mechanism was designed to be implemented
so that *no* additional overhead is required
if an exception is not thrown.
If an exception is thrown, a great deal of extra computation
may be required to handle it.

The exception handling mechanism should *not* be used
to detect and locate programming errors (bugs).
Programming errors are *not* exceptions
because they are not expected
and are both predictable and preventable once detected.

Exceptions are not always errors.
They may be events, such as running out of memory,
over which your program has no control.
Listen to your coworkers.
From what you have told us,
it appears that they know what they are talking about.

[E. Robert Tisdale]

Cy Edmunds wrote:

Scott Brady Drummonds wrote:
[snip]
I never could figure out how
use of exceptions could cause such big run time errors.
If you use them properly as error handlers rather than control structures
Although Scott doesn't say this,
I suspect that this is what his coworkers are complaining about.
they won't be invoked often enough to run up much execution time.
And if you avoid exception specifications
(which are basically useless anyway)
they don't have much overhead at all.

The assumption is that exceptions are rarely thrown.

[Igor Okulist]

> they won't be invoked often enough to run up much execution time
What is I hear that to setup try block does cost CPU time?
Which actually makes sense to me, since the program has to setup
unwind information.

I would imagine your program have more or less localized exception
handling, as opposed to :

main()
{
try{
doeverythingelse();
}catch(...){
printf("caught exception");
}

Anybody wants to add more details on this issue?

Actually the biggest issue with exceptions for me is that you cannot
through them across library boundary, especially if the libs are done
with different compilers. (although its not exactly exceptions fault, the
problem still stands)

Igor

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cm**********@nntp1.jpl.nasa.gov...

Cy Edmunds wrote:

Scott Brady Drummonds wrote:

[snip]

I never could figure out how
use of exceptions could cause such big run time errors.
If you use them properly as error handlers

rather than control structures

Although Scott doesn't say this,
I suspect that this is what his coworkers are complaining about.

they won't be invoked often enough to run up much execution time.
And if you avoid exception specifications
(which are basically useless anyway)
they don't have much overhead at all.

The assumption is that exceptions are rarely thrown.

[Markus Elfring]

> And if you avoid exception specifications (which are basically useless

anyway) they don't have much overhead at all.

I disagree.
- An interface designer can specify the expected error values so that
the developer or programmer must adhere to such restrictions in the
implementation.

- If the an exception specification is omitted, the compiler (that
does not perform inter-procedural analysis) must assume that every
possible exception can be thrown and must be prepared to generate code
for the handling of stack unwinding and related stuff. This detail can
be optimized if you add "throw()" to your functions and methods
because no exceptions will be thrown.

Regards,
Markus

[Lionel B]

Markus Elfring wrote:

And if you avoid exception specifications (which are
basically useless anyway) they don't have much overhead at all.

I disagree.

I agree (with your disagreement).

I recently benchmarked some highly optimised low-level number-crunching
code with and without exception handling [floating point exception
trapping was not enabled in either case]. Even when no exceptions were
being thrown there was a performance hit of about 20% with exception
handling enabled [with or without explicit exception specification -
this didn't seem to make much difference].

--
Lionel B

[Markus Elfring]

> Besides the Meyers books and my trusty copy of "C++ FAQs", I'm going on my

intuition based on years of experience. Am I over-indoctrinated in the use
of exceptions? Are there some warnings that I'm not heeding? Can
exceptions impact performance to the degree that my coworkers claim? I'd
like to hear some anti-exception thoughts, if they exist.

Would you like to develop for evironments with very limited resources?
How do you think about this article by P. J. Plauger?

Embedded C++: An Overview
Is EC++ the diet pill that will shrink C++ down to size for embedded applications?
http://www.ghs.com/download/ec++.pdf

[Lionel B]

E. Robert Tisdale wrote:

The exception handling mechanism was designed to be implemented
so that *no* additional overhead is required
if an exception is not thrown.

Not sure quite what you mean by "was designed to be implemented"... in
my experience (well, mainly with gcc) even if exceptions are not thrown
performance is nevertheless (quite substantially) impacted by the
exception handling mechanism. It is difficult to see how this could not
be the case: even if exceptions are not thrown the compiler has to
allow for the possiblity that exceptions *might* be thrown. This
implies at the very least that it must store stack unwinding
information somewhere, which will surely incur an overhead.
--
Lionel B

[Alf P. Steinbach]

* Lionel B:

E. Robert Tisdale wrote:

The exception handling mechanism was designed to be implemented
so that *no* additional overhead is required
if an exception is not thrown.

Not sure quite what you mean by "was designed to be implemented"... in
my experience (well, mainly with gcc) even if exceptions are not thrown
performance is nevertheless (quite substantially) impacted by the
exception handling mechanism. It is difficult to see how this could not
be the case: even if exceptions are not thrown the compiler has to
allow for the possiblity that exceptions *might* be thrown. This
implies at the very least that it must store stack unwinding
information somewhere, which will surely incur an overhead.

Well, no, I think all the necessary _dynamic_ stack unwinding information is
present in the chain of return adresses which you have anyway. All you
have to do, in theory, is to compare the current execution address plus
each return address to a statically compiled table of exception handlers,
and check the exception type against ditto statically compiled information.
At least as far as I can see, not having implemented a C++ compiler.

But that's theory.

Reality is something else, where e.g. Visual C++ supports native
Windows SEH exceptions so that execution of the outermost 'try' in
a function is not a no-op, and where an exception can pass up through a
linkage boundary (in standard C++ there is only the one program, in real C++
there are dynamic libraries). Your comment about gcc is a bit vague, though.
If I recall correctly the internal exception mechanism in gcc was changed in
some version, but whether it was from dynamic to more static table-driven or
opposite I don't recall -- presumably each has its pros and cons.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Gianni Mariani]

Scott Brady Drummonds wrote:

Hi, all,

I just got out of a meeting with a team of software developers that I
recently joined as they are staffing to create a medium-sized project
(potentially all of which will be written in C++). From my experience and
readings, I've come to this group indoctrinated to use exceptions for error
handling. The experience in this group that leads them to believe that
exceptions should only be used where severe runtime errors require program
termination is mainly based on the notion that the performance impact of
exceptions is prohibitive.
Just for the record. If your program is incapable of continuing, then it
should abort at the point where the error is detected. This is what
assert() is for.

Besides the Meyers books and my trusty copy of "C++ FAQs", I'm going on my
intuition based on years of experience. Am I over-indoctrinated in the use
of exceptions? Are there some warnings that I'm not heeding? Can
exceptions impact performance to the degree that my coworkers claim? I'd
like to hear some anti-exception thoughts, if they exist.

The biggest problem I have with exception use is that it's nigh
impossible to figure out what went wrong when somthing bad happens.
This may be an implementation issue rather than a specification issue
but without a reliable way of figuring out what happened when, I really
can't reccomend it's use.

e.g. consider this mock up code (just one example)
struct X
{
void F1( X * x ) throw()
{
x->F2(); // somwhere we need to call F2.
}

virtual void F2() = 0;
};

struct Y : X
{

virtual void F2()
{
// ... bad thing happened

throw int(1); // post-mortem does not show this line at all
}
};

int main()
{
Y y[1];

X * x = y;

x->F1( x );
}

The program dumps core because the default "unexpected()" is called in
the context of F1 where it promptly dumps core. All the knowledge of
what happened is lost. No stack frames, no thrown object, NADA.
#0 0x401545c1 in kill () from /lib/libc.so.6
#1 0x40154355 in raise () from /lib/libc.so.6
#2 0x4015589b in abort () from /lib/libc.so.6
#3 0x400bb1cd in __gnu_cxx::__verbose_terminate_handler ()
at ../../../../gcc-3.4.0/libstdc++-v3/libsupc++/vterminate.cc:96
#4 0x400b9220 in __cxxabiv1::__terminate (handler=0x400bb0dc
<__gnu_cxx::__verbose_terminate_handler()>)
at ../../../../gcc-3.4.0/libstdc++-v3/libsupc++/eh_terminate.cc:43
#5 0x400b9258 in std::terminate () at
.../../../../gcc-3.4.0/libstdc++-v3/libsupc++/eh_terminate.cc:53
#6 0x400b926c in __cxxabiv1::__unexpected (handler=0x400b9238
<std::terminate()>)
at ../../../../gcc-3.4.0/libstdc++-v3/libsupc++/eh_terminate.cc:59
#7 0x400b9162 in __cxa_call_unexpected (exc_obj_in=0x8049b28)
at ../../../../gcc-3.4.0/libstdc++-v3/libsupc++/eh_personality.cc:486
#8 0x0804876a in X::F1 ()
#9 0x08048728 in main ()

[Lionel B]

Gianni Mariani wrote:

Just for the record. If your program is incapable of
continuing, then it should abort at the point where
the error is detected. This is what assert() is for.

And if your "program" is actually a library which other (people's)
programs are going to link to...?

Another viewpoint is that if your program is incapable of continuing -
at least for any other reason than physical limitations (head crash,
CPU explodes, etc.) - then that is programmer error.

As an example, I have written a number of C++ library routines to be
called from the Gauss linear algebra system (think Matlab but
clunkier). If my library code aborts... so does Gauss! My users do not
appreciate this. So I use exceptions to recover elegantly from
(unforseeable) situations such as resource exhaustion, then deliver an
informative explanatory message to the user ("Out of memory. Yes YOU
used it all up. Pig.", etc.).

--
Lionel B

[Lionel B]

Gianni Mariani wrote:

Just for the record. If your program is incapable of
continuing, then it should abort at the point where
the error is detected. This is what assert() is for.

And if your "program" is actually a library which other (people's)
programs are going to link to...?

Another viewpoint is that if your program is incapable of continuing -
at least for any other reason than physical limitations (head crash,
CPU explodes, etc.) - then that is programmer error.

As an example, I have written a number of C++ library routines to be
called from the Gauss linear algebra system (think Matlab but
clunkier). If my library code aborts... so does Gauss! My users do not
appreciate this. So I use exceptions to recover elegantly from
(unforseeable) situations such as resource exhaustion, then deliver an
informative explanatory message to the user ("Out of memory. Yes YOU
used it all up. Pig.", etc.).

--
Lionel B

[Lionel B]

Gianni Mariani wrote:

Just for the record. If your program is incapable of
continuing, then it should abort at the point where
the error is detected. This is what assert() is for.

And if your "program" is actually a library which other (people's)
programs are going to link to...?

Another viewpoint is that if your program is incapable of continuing -
at least for any other reason than physical limitations (head crash,
CPU explodes, etc.) - then that is programmer error.

As an example, I have written a number of C++ library routines to be
called from the Gauss linear algebra system (think Matlab but
clunkier). If my library code aborts... so does Gauss! My users do not
appreciate this. So I use exceptions to recover elegantly from
(unforseeable) situations such as resource exhaustion, then deliver an
informative explanatory message to the user ("Out of memory. Yes YOU
used it all up. Pig.", etc.).

--
Lionel B

[Lionel B]

Gianni Mariani wrote:

Just for the record. If your program is incapable of
continuing, then it should abort at the point where
the error is detected. This is what assert() is for.

And if your "program" is actually a library which other (people's)
programs are going to link to...?

Another viewpoint is that if your program is incapable of continuing -
at least for any other reason than physical limitations (head crash,
CPU explodes, etc.) - then that is programmer error.

As an example, I have written a number of C++ library routines to be
called from the Gauss linear algebra system (think Matlab but
clunkier). If my library code aborts... so does Gauss! My users do not
appreciate this. So I use exceptions to recover elegantly from
(unforseeable) situations such as resource exhaustion, then deliver an
informative explanatory message to the user ("Out of memory. Yes YOU
used it all up. Pig.", etc.).

--
Lionel B

[Cy Edmunds]

"Markus Elfring" <Ma************@web.de> wrote in message
news:40**************************@posting.google.c om...

And if you avoid exception specifications (which are basically useless
anyway) they don't have much overhead at all.

I disagree.
- An interface designer can specify the expected error values so that
the developer or programmer must adhere to such restrictions in the
implementation.

- If the an exception specification is omitted, the compiler (that
does not perform inter-procedural analysis) must assume that every
possible exception can be thrown and must be prepared to generate code
for the handling of stack unwinding and related stuff. This detail can
be optimized if you add "throw()" to your functions and methods
because no exceptions will be thrown.

Regards,
Markus

http://www.gotw.ca/publications/mill22.htm

--
Cy
http://home.rochester.rr.com/cyhome/

[Cy Edmunds]

"Igor Okulist" <ok****@hotmail.com> wrote in message
news:Xw******************@newssvr21.news.prodigy.c om...

they won't be invoked often enough to run up much execution time

What is I hear that to setup try block does cost CPU time?
Which actually makes sense to me, since the program has to setup
unwind information.

I would imagine your program have more or less localized exception
handling, as opposed to :

main()
{
try{
doeverythingelse();
}catch(...){
printf("caught exception");
}

Anybody wants to add more details on this issue?

Actually the biggest issue with exceptions for me is that you cannot
through them across library boundary, especially if the libs are done
with different compilers. (although its not exactly exceptions fault, the
problem still stands)

Igor

[snip]

You have to compare

try{
dosomething();
} catch(...) {
fixit();
}

with

err_code = dosomething();
if (error_code)
fixit();

Both take run time although I wouldn't call it overhead -- good error
handling isn't optional. I find the former style clearer and much easier to
maintain.

--
Cy
http://home.rochester.rr.com/cyhome/

[Cy Edmunds]

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:zo********************@speakeasy.net...

Scott Brady Drummonds wrote:

Hi, all,

I just got out of a meeting with a team of software developers that I
recently joined as they are staffing to create a medium-sized project
(potentially all of which will be written in C++). From my experience
and
readings, I've come to this group indoctrinated to use exceptions for
error
handling. The experience in this group that leads them to believe that
exceptions should only be used where severe runtime errors require
program
termination is mainly based on the notion that the performance impact of
exceptions is prohibitive.
Just for the record. If your program is incapable of continuing, then it
should abort at the point where the error is detected. This is what
assert() is for.

Besides the Meyers books and my trusty copy of "C++ FAQs", I'm going on
my
intuition based on years of experience. Am I over-indoctrinated in the
use
of exceptions? Are there some warnings that I'm not heeding? Can
exceptions impact performance to the degree that my coworkers claim? I'd
like to hear some anti-exception thoughts, if they exist.

The biggest problem I have with exception use is that it's nigh impossible
to figure out what went wrong when somthing bad happens. This may be an
implementation issue rather than a specification issue but without a
reliable way of figuring out what happened when, I really can't reccomend
it's use.

e.g. consider this mock up code (just one example)
struct X
{
void F1( X * x ) throw()

Why use exception specifications? See
http://www.gotw.ca/publications/mill22.htm
{
x->F2(); // somwhere we need to call F2.
}

virtual void F2() = 0;
};

struct Y : X
{

virtual void F2()
{
// ... bad thing happened

throw int(1); // post-mortem does not show this line at all
You throw an int and then complain that exceptions don't help you trace the
problem? I assume you realize that you can throw a class instance here which
contains all the relevant post-mortem information -- or better yet,
information required to fix the problem and continue.
}
};

int main()
{
Y y[1];

X * x = y;

x->F1( x );
}

The program dumps core because the default "unexpected()" is called in the
context of F1 where it promptly dumps core. All the knowledge of what
happened is lost. No stack frames, no thrown object, NADA.
The unexpected call is a result of your using a throw specification.


#0 0x401545c1 in kill () from /lib/libc.so.6
#1 0x40154355 in raise () from /lib/libc.so.6
#2 0x4015589b in abort () from /lib/libc.so.6
#3 0x400bb1cd in __gnu_cxx::__verbose_terminate_handler ()
at ../../../../gcc-3.4.0/libstdc++-v3/libsupc++/vterminate.cc:96
#4 0x400b9220 in __cxxabiv1::__terminate (handler=0x400bb0dc
<__gnu_cxx::__verbose_terminate_handler()>)
at ../../../../gcc-3.4.0/libstdc++-v3/libsupc++/eh_terminate.cc:43
#5 0x400b9258 in std::terminate () at
../../../../gcc-3.4.0/libstdc++-v3/libsupc++/eh_terminate.cc:53
#6 0x400b926c in __cxxabiv1::__unexpected (handler=0x400b9238
<std::terminate()>)
at ../../../../gcc-3.4.0/libstdc++-v3/libsupc++/eh_terminate.cc:59
#7 0x400b9162 in __cxa_call_unexpected (exc_obj_in=0x8049b28)
at ../../../../gcc-3.4.0/libstdc++-v3/libsupc++/eh_personality.cc:486
#8 0x0804876a in X::F1 ()
#9 0x08048728 in main ()

--
Cy
http://home.rochester.rr.com/cyhome/

[Tom Widmer]

On 9 Nov 2004 08:42:40 -0800, "Lionel B" <go****@lionelb.com> wrote:

Gianni Mariani wrote:

Just for the record. If your program is incapable of
continuing, then it should abort at the point where
the error is detected. This is what assert() is for.
And if your "program" is actually a library which other (people's)
programs are going to link to...?

Another viewpoint is that if your program is incapable of continuing -
at least for any other reason than physical limitations (head crash,
CPU explodes, etc.) - then that is programmer error.

Right, and that's what assert helps with, by providing core dumps,
etc. Obviously, an application might want to have its own version of
assert that displays the error to the user before terminating, or
whatever.
As an example, I have written a number of C++ library routines to be
called from the Gauss linear algebra system (think Matlab but
clunkier). If my library code aborts... so does Gauss! My users do not
appreciate this. So I use exceptions to recover elegantly from
(unforseeable) situations such as resource exhaustion, then deliver an
informative explanatory message to the user ("Out of memory. Yes YOU
used it all up. Pig.", etc.).

Yes, that's what exceptions are for - *expected* exceptional
circumstances, not bugs. For example, resource exhaustion, invalid
input from files you don't control, etc. For a robust library
component such as you describe, this may include invalid parameters.

Tom

[Old Wolf]

Gianni Mariani <gi*******@mariani.ws> wrote:

The biggest problem I have with exception use is that it's nigh
impossible to figure out what went wrong when somthing bad happens.
Look at the what() member function of the exception.
It returns a pointer to a string that describes exactly
what went wrong.
e.g. consider this mock up code (just one example)

struct X
{
void F1( X * x ) throw()
{
x->F2(); // somwhere we need to call F2.
}
virtual void F2() = 0;
};
The program dumps core because the default "unexpected()" is called in
the context of F1 where it promptly dumps core. All the knowledge of
what happened is lost. No stack frames, no thrown object, NADA.

In the definition of F1 you promised that it would not throw.
Then you perform an operation that could throw. This is
entirely a case of programmer error. Would you also say
that one should not use "const" because of:
const int x = 1;
*(int *)&x = 2;
causing the program to abort?

Some guidelines I find useful:
- don't use throw specifications
- in main(): try { do_everything(); }
catch(std::exception const &e) { ...e.what()...... }
catch(...) { ......... }

[Lionel B]

Tom Widmer wrote:

On 9 Nov 2004 08:42:40 -0800, "Lionel B" <go****@lionelb.com> wrote:

Gianni Mariani wrote:

Just for the record. If your program is incapable of
continuing, then it should abort at the point where
the error is detected. This is what assert() is for.

And if your "program" is actually a library which other
(people's) programs are going to link to...?

Another viewpoint is that if your program is incapable
of continuing - at least for any other reason than physical
limitations (head crash, CPU explodes, etc.) - then that
is programmer error.

Right, and that's what assert helps with, by providing core dumps,
etc. Obviously, an application might want to have its own version of
assert that displays the error to the user before terminating, or
whatever.

Right. As I say my library routine simply cannot afford to terminate...
so the easiest resolution is that in any section of code where I might
be tempted to use assert, I would rather throw an exception on the
"bad" condition (I won't call it a "bug", as a bug is by [my]
definition a bad condition that you *didn't* anticipate) and catch it
in the library function called by the user. Ok, I don't get a core
dump, but as I say my program simply may not terminate. Put another
way, my "version of assert" [at least in non-debug mode] throws an
exception...

Of course there may still be bugs - bad conditions that I failed to
anticipate - that may cause my routine to abort.

--
Lionel B

[Tom Widmer]

On 10 Nov 2004 01:04:35 -0800, "Lionel B" <go****@lionelb.com> wrote:

Tom Widmer wrote:

On 9 Nov 2004 08:42:40 -0800, "Lionel B" <go****@lionelb.com> wrote:

>Gianni Mariani wrote:
>> Just for the record. If your program is incapable of
>> continuing, then it should abort at the point where
>> the error is detected. This is what assert() is for.
>
>And if your "program" is actually a library which other
>(people's) programs are going to link to...?
>
>Another viewpoint is that if your program is incapable
>of continuing - at least for any other reason than physical
>limitations (head crash, CPU explodes, etc.) - then that
>is programmer error.
Right, and that's what assert helps with, by providing core dumps,
etc. Obviously, an application might want to have its own version of
assert that displays the error to the user before terminating, or
whatever.

Right. As I say my library routine simply cannot afford to terminate...
so the easiest resolution is that in any section of code where I might
be tempted to use assert, I would rather throw an exception on the
"bad" condition (I won't call it a "bug", as a bug is by [my]
definition a bad condition that you *didn't* anticipate) and catch it
in the library function called by the user.

asserts aren't conditions that you anticipate will happen, but rather
conditions that you know will be true. If they are false, then
something has gone horribly wrong, and the software contains a bug.

Ok, I don't get a coredump, but as I say my program simply may not terminate.
This does make it harder to find bugs - users may not report the
problem if it doesn't inconvenience them, and they won't have an kind
of core dump to send you. Obviously, minimizing the problem through
testing is the key.

Put anotherway, my "version of assert" [at least in non-debug mode] throws an
exception...

Of course there may still be bugs - bad conditions that I failed to
anticipate - that may cause my routine to abort.

If you are using Win32, you could use SEH to try to "catch" these too.

Tom

[Markus Elfring]

> >> And if you avoid exception specifications (which are basically useless

anyway) they don't have much overhead at all.

I disagree.
[...]

http://www.gotw.ca/publications/mill22.htm

1. Herb Sutter describes some strong arguments in the article "A
Pragmatic Look at Exception Specifications".
I see a problem in the level of support for the enforcement of
exception specifications. There seems to be a gap between the
expectations of the standard and the quality of current compiler
implementations.

2. Would you like to look at the assembler instructions to examine how
much this topic makes a difference in code size for your compiler?

Regards,
Markus

[Markus Elfring]

> - An interface designer can specify the expected error values so that

the developer or programmer must adhere to such restrictions in the
implementation.
This checking is performed at run time.

- If the an exception specification is omitted, the compiler (that
does not perform inter-procedural analysis) must assume that every
possible exception can be thrown and must be prepared to generate code
for the handling of stack unwinding and related stuff. This detail can
be optimized if you add "throw()" to your functions and methods
because no exceptions will be thrown.

Exception specifications add generated code to the function or method
implementation to handle unexpected exceptions.
The caller can try to benefit from a "throws nothing" contract at
compile time.

=> You must consider at which time you would like to use the services
and to adjust your expectations.

[Ron House]

Cy Edmunds wrote:

You have to compare

try{
dosomething();
} catch(...) {
fixit();
}

with

err_code = dosomething();
if (error_code)
fixit();

The big hit comes when dosomething() is not the raw routine that
discovered the error. Then the err_code method has to pass the failure
all the way out, testing stuff at every level. In that case the former,
as you say, wins big time.

--
Ron House ho***@usq.edu.au
http://www.sci.usq.edu.au/staff/house

[Igor Okulist]

"Ron House" <ho***@usq.edu.au> wrote in message
news:41**************@usq.edu.au...

Cy Edmunds wrote:

You have to compare

try{
dosomething();
} catch(...) {
fixit();
}

with

err_code = dosomething();
if (error_code)
fixit();

The big hit comes when dosomething() is not the raw routine that
discovered the error. Then the err_code method has to pass the failure
all the way out, testing stuff at every level. In that case the former,
as you say, wins big time.

Actually in the example :

try{
dosomething();
} catch(...) {
fixit();
}

I often don't see possibility to "fix" much with a "fixit()", basically
just clean up and pass the same error code up to the calling function.

So, on error just clean up resource and pass it back, to let the calling
function try again, hopefully with better input parameters or bail out.

Most of the my resource are reference counted (and if not then I write a
small wrapper around them that would clean up, once it goes out of
scope). In such case
err_code = dosomething();
if (error_code)
fixit();

becomes:

err_code = dosomething();
if (error_code) return error_code;

and i have a habit of having all return codes of less than 0 fatal error
codes, so with a macro the code becomes:
err_code = dosomething();
RETURN_ON_FAILED_MACRO(error_code);

The macro also brings in __FILE__ and __LINE__ and prints with printf or
custom log function. Now, if error happens I get a very nice call stack on
the log output. And once the __FUNCTION__ macro becomes available
the log will be even better. In this way I don't really see need to use
try/catch
constructs everywhere (yes, there ARE case when the are needed).

Any thoughts?

Regards,
Igor

[Herb Sutter]

On Mon, 8 Nov 2004 15:33:57 -0800, "Scott Brady Drummonds"
<sc**********************@intel.com> wrote:

I just got out of a meeting with a team of software developers that I
recently joined as they are staffing to create a medium-sized project
(potentially all of which will be written in C++). From my experience and
readings, I've come to this group indoctrinated to use exceptions for error
handling. The experience in this group that leads them to believe that
exceptions should only be used where severe runtime errors require program
termination is mainly based on the notion that the performance impact of
exceptions is prohibitive.

Besides the Meyers books and my trusty copy of "C++ FAQs", I'm going on my
intuition based on years of experience. Am I over-indoctrinated in the use
of exceptions? Are there some warnings that I'm not heeding? Can
exceptions impact performance to the degree that my coworkers claim? I'd
like to hear some anti-exception thoughts, if they exist.

Several responders already noted my article "When and How to Use
Exceptions" (C/C++ Users Journal, 22(8), August 2004). It's drawn from
Items 70 to 72 of C++ Coding Standards
(www.gotw.ca/publications/c++cs.htm).

In particular, Item 72 argues "Prefer to use exceptions to report errors."
And in particular it argues that exceptions are not for normal processing
(stuff that doesn't cause a function to fail to achieve its documented
results), which is why 72 builds on Item 70 "Distinguish between errors
and non-errors."

Herb
---
Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Architect, Developer Division, Microsoft (www.gotw.ca/microsoft)