Why do some code bases don't use exceptions?

[krel]

I've seen it mentioned in several places that some code bases - open
source projects or proprietary company code - deliberately choose not
use exceptions in their C++ code. The only example I can come up with at
the moment is are the Google C++ guidelines however, I've seen that
notions expressed in various places.

What are some reason that a project would choose not to use C++ exceptions?

krel

 

[Ian Collins]

I've seen it mentioned in several places that some code bases - open
source projects or proprietary company code - deliberately choose not
use exceptions in their C++ code. The only example I can come up with at
the moment is are the Google C++ guidelines however, I've seen that
notions expressed in various places.

What are some reason that a project would choose not to use C++ exceptions?

Lack off, or poor compiler support.

 

[James Kanze]

Lack off, or poor compiler support.

Today? Except possibly for very small embedded systems. Fear,
uncertainy and doubt about compiler support, maybe, but
exceptions are probably more stable than templates or RTTI
today.

Interoperatability with C would seem to me to be a more
significant reason. If an entire project is written in C++, I
don't see any real problem, but if you have C++ functions called
from C, and vice versa, you might want to pay attention.

It would also be interesting to know just what role these
guidelines play within Google. They don't seem very
appropriate; several of them actually violate best established
Any complex initialization should go in an explicit Init()
method. practice ("Any complex initialization should go in an
explicit Init() method", for example). Google certainly has
some exceptionally competent C++ programmers, but they don't
seem to have been involved here.

 

[Bo Persson]

Today? Except possibly for very small embedded systems. Fear,
uncertainy and doubt about compiler support, maybe, but
exceptions are probably more stable than templates or RTTI
today.

Interoperatability with C would seem to me to be a more
significant reason. If an entire project is written in C++, I
don't see any real problem, but if you have C++ functions called
from C, and vice versa, you might want to pay attention.

It would also be interesting to know just what role these
guidelines play within Google. They don't seem very
appropriate; several of them actually violate best established
Any complex initialization should go in an explicit Init()
method. practice ("Any complex initialization should go in an
explicit Init() method", for example). Google certainly has
some exceptionally competent C++ programmers, but they don't
seem to have been involved here.

Google also has tons of old code that was written without proper
support for exceptions. That's their main reason for not using it -
legacy code!


Bo Persson

 

[James Kanze]

Google also has tons of old code that was written without
proper support for exceptions. That's their main reason for
not using it - legacy code!

That's a good point. Exceptions when code isn't exception safe
are a sure recepe for disaster, and code written before
exception safety was known or understood generally won't be
exception safe.

 

[Ian Collins]

Today? Except possibly for very small embedded systems. Fear,
uncertainy and doubt about compiler support, maybe, but
exceptions are probably more stable than templates or RTTI
today.

I hope they have updated it now, but up to a couple of years ago the
Green Hill C++ compiler had a really poor exception implementation. So
bad we had to remove exceptions from our code.

 

[krel]

Today? Except possibly for very small embedded systems. Fear,
uncertainy and doubt about compiler support, maybe, but
exceptions are probably more stable than templates or RTTI
today.

I probably should have added RTTI and templates to my original question
but I as I understand from your answer the main reasons for companies
not to use exceptions, templates or RTTI are:

1) Lack of compiler support
2) Does not integrate well with old code

Is that right? What I mean is that the reasons are not related to the
actual functionality of the feature, as in "X is a broken and badly
designed feature".

krel

 

[Shaun Deacon]

I probably should have added RTTI and templates to my original question

Another reason could be wanting statically built executables (There
are problems trying to link libstdc++ statically when compiling with g+
+ for example). The following link gives some detailed background :

http://www.trilithium.com/johan/2005/06/static-libstdc

best regards,
Shaun

 

[Greg Herlihy]

What are some reason that a project would choose not to use C++ exceptions?

Because the program (or more likely, the library) has no exceptional
states.

Greg

 

[James Kanze]

(1) might be an issue, but actually it should not, after
having the C++ standard around for more than 10 years already.

Yes and no. How many compilers do you know that implement
standard conforming templates (including export)? It is still
an issue.

In the end, you weigh the advantages and the disadvantages, and
make a choice. Not using std::vector, and having to use
<generic.h> for your own generic classes, makes banning
templates completely a non-starter, regardless of how poorly
they are (typically) implemented.

Regarding (2), RTTI and templates are local features, so the
integration should be no big concern.

Exactly. The "existing code" argument mainly affects
exceptions, and not much else.

In C++, there are surprisingly few "broken and badly designed
features".

That's very arguable. The question isn't so much whether C++
does it right; it's usually a question of other languages not
supporting it at all.

Non-empty exception specifications are one example,

Broken and badly designed, or simply a more or less good
solution without a problem?

the "most-vexing-c++- parse" another. The latter was kept for
C compatibility, but I strongly suspect the amount of C code
saved this way is very close to zero.

Are you kidding? Take a look at any of the C headers on your
machine. How many systematically use "extern" before function
declarations, and how many just count on the fact that a
function declaration is always "extern", unless specified
otherwise.

Regarding Google, maybe they might have banned exceptions
because of the run-time overhead (just guessing). Throwing
exceptions is notoriously slow, so they should not be used
unless something goes very wrong - but for a 24/7 service like
Google nothing should go wrong ever, so no need for
exceptions, right?

If something truely goes wrong, you should have an assertion
failure, not an exception. Exceptions are for things that
exceptionally occur. Seriously, exceptions are the preferred
solution when the error is expected, but very infrequently, and
cannot reasonably be handled locally, by the calling function.
(Depending on context, I imagine that something like a dropped
connection could be reasonably reported by an exception. And it
would certainly be unrealistic for Google to expect never to see
one of those.)

 

[James Kanze]

Another reason could be wanting statically built executables
(There are problems trying to link libstdc++ statically when
compiling with g++ for example). The following link gives
some detailed background :

http://www.trilithium.com/johan/2005/06/static-libstdc

Despite the author's erroneous conclusions, that paper actually
explains why you should always link libstdc++ statically.

 

[Brian]

Today? Except possibly for very small embedded systems. Fear,
uncertainy and doubt about compiler support, maybe, but
exceptions are probably more stable than templates or RTTI
today.

Interoperatability with C would seem to me to be a more
significant reason. If an entire project is written in C++, I
don't see any real problem, but if you have C++ functions called
from C, and vice versa, you might want to pay attention.

I'm not sure why you say "vice versa." If you have C functions
called from C++, what's the problem? You just check the return
code and throw or proceed.

I've been trying to figure out what I should do with exceptions
and return codes for years. Currently I'm trying to support
both, but it is difficult to do so well. Most libraries I can
think of offer one or the other. Boost just uses exceptions
I think. I'm leaning toward dropping support for return codes.

It would also be interesting to know just what role these
guidelines play within Google. They don't seem very
appropriate; several of them actually violate best established
Any complex initialization should go in an explicit Init()
method. practice ("Any complex initialization should go in an
explicit Init() method", for example).

It looks like you still need to get some furniture.


Brian Wood
http://webEbenezer.net

 

[Jorgen Grahn]

.

Regarding Google, maybe they might have banned exceptions because of the
run-time overhead (just guessing). Throwing exceptions is notoriously
slow,

Says who? Maybe you're right, for some value of "notoriously", but
I'm asking because that's a statement which gets thrown around a lot
with no data to back it up.

so they should not be used unless something goes very wrong - but
for a 24/7 service like Google nothing should go wrong ever, so no need
for exceptions, right?

(I'm assuming you're not joking)

Flawed logic. If nothing should go wrong, the alleged slowness of
throwing and catching is irrelevant, and no longer a reason to avoid
exceptions.

/Jorgen

 

[Richard Herring]

In message

I'm not sure why you say "vice versa." If you have C functions
called from C++, what's the problem? You just check the return
code and throw or proceed.

He says "_and_ vice versa."

If C++ function g() is called from C function f() which is called from
C++ main(), what happens if g() throws an exception?

 

[Brian]

In message





He says "_and_ vice versa."

If C++ function g() is called from C function f() which is called from
C++ main(), what happens if g() throws an exception?

Whoever wrote f() should be fired.


Brian Wood
http://webEbenezer.net

 

[dragan]

I've seen it mentioned in several places that some code bases - open
source projects or proprietary company code - deliberately choose not
use exceptions in their C++ code. The only example I can come up with
at the moment is are the Google C++ guidelines however, I've seen that
notions expressed in various places.

What are some reason that a project would choose not to use C++
exceptions?

Because:

1. The "exception goto" creates spaghetti code.
2. Developers use them as a crutch instead of solving problems.
3. They don't understand them.
4. It would be easier to build a space shuttle.
5. They are not necessary.
6. They use other techniques.
7. They can't afford a C++ guru consultant.
8. They constrain the system design.
9. Google said they were bad.
10. All of the above.
11. Some of the above.
12. Other reason.

 

[dragan]

Today? Except possibly for very small embedded systems. Fear,
uncertainy and doubt about compiler support, maybe, but
exceptions are probably more stable than templates or RTTI
today.

Interoperatability with C would seem to me to be a more
significant reason. If an entire project is written in C++, I
don't see any real problem, but if you have C++ functions called
from C, and vice versa, you might want to pay attention.

It would also be interesting to know just what role these
guidelines play within Google. They don't seem very
appropriate; several of them actually violate best established
Any complex initialization should go in an explicit Init()
method. practice

("Any complex initialization should go in an
explicit Init() method", for example).

Maybe it should and maybe constructors should be able to call other
constructors. So that one that you picked is probably not that bad. If that
is the case, exceptions don't look as useful. Maybe C++ is suitable ONLY for
large scale development? The exception (no pun) imposing on the common case
again?

 

[dragan]

That's a good point. Exceptions when code isn't exception safe
are a sure recepe for disaster, and code written before
exception safety was known or understood generally won't be
exception safe.

How long is the book on writing exception safe code? Or, how many books are
there? Or, is there a web page that sums it up quite nicely? Is it just a
few rules of thumb?

 

[dragan]

In C++, there are surprisingly few "broken and badly designed
features".

Opinions vary. The guy who wrote the recent post "Article on possible
improvements to C++" disagrees with your statement.

 

[White Wolf]

Because:

1. The "exception goto" creates spaghetti code.

It is not a goto. It does not specify where it goes. It reports an
error detected by the thrower to the handler declared by the catch
statement.

2. Developers use them as a crutch instead of solving problems.

A sweeping generalization.

3. They don't understand them.

A sweeping generalization.

4. It would be easier to build a space shuttle.

False statement.

5. They are not necessary.

False statement. Any constructor that may fail and nearly any use of
the standard library will require exceptions.

6. They use other techniques.

There are no other techniques for the above mentioned 2 cases.

7. They can't afford a C++ guru consultant.

They don't need to. All they need to be able to afford is a copy of
Effective C++ 3rd edition.

8. They constrain the system design.

Yeah, they constrain it. That was the statement, i cannot se how it can
also be the reason.

9. Google said they were bad.

I doubt it. Google is represented (today I think) by 3 people at the
C++ standardization committee. IIRC all of them has participated in
designing and voting on the exception features for the first standard.

10. All of the above.
11. Some of the above.
12. Other reason.

I vote for this one. Ignorance and prejudice comes into my mind...