Why do some code bases don't use exceptions?

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

krel wrote:
> 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.

--
Ian Collins

On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
> krel wrote:
> > 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.

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.

--
James Kanze

James Kanze wrote:
> On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> krel wrote:
>>> 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.
>
> 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

On Nov 17, 5:10 pm, "Bo Persson" <b...@gmb.dk> wrote:
> James Kanze wrote:
> > On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> krel wrote:
> >>> 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.

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

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.

--
James Kanze

James Kanze wrote:
> On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> krel wrote:
>>> 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.
>
> 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.

--
Ian Collins

James Kanze wrote:

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

krel <krel@example.invalid> wrote in news:hduq8e$4f9$1@news.eternal-
september.org:

> James Kanze wrote:
>
>>
>> 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?

(1) might be an issue, but actually it should not, after having the C++
standard around for more than 10 years already. Regarding (2), RTTI and
templates are local features, so the integration should be no big
concern.

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

In C++, there are surprisingly few "broken and badly designed features".
Non-empty exception specifications are one example, 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.

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?


Cheers
Paavo

On Nov 17, 11:37*am, krel <k...@example.invalid> wrote:

> 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

On Nov 16, 11:26*pm, krel <k...@example.invalid> wrote:

> 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

On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> krel <k...@example.invalid> wrote innews:hduq8e$4f9$1@news.eternal-
> september.org:
> > James Kanze wrote:

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

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

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

> 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

On Nov 18, 1:44 am, Shaun Deacon <sdea...@fma.fujitsu.com> wrote:
> On Nov 17, 11:37 am, krel <k...@example.invalid> wrote:

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

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

--
James Kanze

On Nov 17, 3:16 am, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > krel wrote:
> > > 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.
>
> 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

On Tue, 2009-11-17, Paavo Helde wrote:
....
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

In message
<6168959f-a70f-47e9-be39-038b46199cc8@s31g2000yqs.googlegroups.com>,
Brian <coal@mailvault.com> writes
>On Nov 17, 3:16 am, James Kanze <james.ka...@gmail.com> wrote:
>> On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>> > krel wrote:
>> > > 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.
>>
>> 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.

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?

--
Richard Herring