Exception Specifications

Exception Specifications

[Perry Smith]

I believe I saw in some of the boost libraries that they do not use  
exception specifications because some compilers produce slower code.

I'm considering adding exception specifications to most/all of my  
functions -- mostly for my own sake.  But I'm wondering how it will  
affect the compiler's generated code.  (i.e. if it is going to affect  
performance, I can put the exception specifications in comments just  
as easily).  I'm currently using gcc 4.0.2.

Thank you,
Perry Smith ( pedz@easesoftware.com )
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems

Re: Exception Specifications

[Ian Lance Taylor]

Perry Smith <pedz@easesoftware.com> writes:

> I believe I saw in some of the boost libraries that they do not use
> exception specifications because some compilers produce slower code.

Adding an exception specification to a function declaration (e.g.,
throw()) should not cause gcc to generate slower code.  In a few cases
it will actually permit gcc to generate faster code.

Ian

Re: Exception Specifications

[John Love-Jensen]

Hi Perry,

I only use "no throw" specification, i.e., throw(), on functions that
absolutely guarantee that they do not throw.  And I use it sparingly, only
on my functions that really shouldn't throw, ever, such as swap functions,
and I know (a priori) that those functions will never throw.

NOTE:  I have been stung by writing a "no throw" function, annotated with
throw(), and even commented in the contract comments, yet someone later put
in some additional "helpful" tracing/debugging facilities that did throw in
some situations... no joy in Mudville.  Caveat emptor.

I do not put itemized throw specifications on functions.

I highly recommend C++ Coding Standards by Sutter and Alexandrescu, in
particular the section on Error Handling and Exceptions.

Moreso, I highly recommend all of Sutter's books on C++.

Sincerely,
--Eljay

Re: Exception Specifications

[Perry Smith]

On Dec 6, 2006, at 9:21 AM, John Love-Jensen wrote:

> Hi Perry,
>
> I only use "no throw" specification, i.e., throw(), on functions that
> absolutely guarantee that they do not throw.  And I use it  
> sparingly, only
> on my functions that really shouldn't throw, ever, such as swap  
> functions,
> and I know (a priori) that those functions will never throw.
>
> NOTE:  I have been stung by writing a "no throw" function,  
> annotated with
> throw(), and even commented in the contract comments, yet someone  
> later put
> in some additional "helpful" tracing/debugging facilities that did  
> throw in
> some situations... no joy in Mudville.  Caveat emptor.
>
> I do not put itemized throw specifications on functions.
>
> I highly recommend C++ Coding Standards by Sutter and Alexandrescu, in
> particular the section on Error Handling and Exceptions.
>
> Moreso, I highly recommend all of Sutter's books on C++.

Thanks.  I've been surfing the past few minutes and bumped into two  
of Sutter's books: Exceptional C++ and More Exceptional C++.  They  
look interesting.

The one place that I'm a little disappointed is that you can do this:

int foo()
{
     throw 92;
}

int dog() nothrow()
{
     foo();
}

Of course, the code produced catches that at run time but I'm looking  
for something somehow to tag my functions so that "mistakes" like  
this are caught at compile time.  (Similar to what happened to you.   
I'm looking for a way to catch that at compile time.)  I wonder if g+ 
+ has a compile time flag to catch that.

Perry Smith ( pedz@easesoftware.com )
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems

Re: Exception Specifications

[John Love-Jensen]

Hi Perry,

> Of course, the code produced catches that at run time but I'm looking
> for something somehow to tag my functions so that "mistakes" like
> this are caught at compile time.  (Similar to what happened to you.
> I'm looking for a way to catch that at compile time.)  I wonder if g+
> + has a compile time flag to catch that.

Alas, no.  Nor do I know of any "C++ Lint" wholistic analysis tool that
provides that information.  (If anyone knows of such a tool, PLEASE share
that information!)

Java's exception scheme is a little more helpful (at compile time) for
abiding by the exception contract.  But C++ is not Java.  And even in Java
there are some caveats, and day-in-day-out Java programmers have their own
list of issues with Java's exception scheme; so it's no bed of roses over in
Java land either.

"If we used Java we wouldn't have these problems;
 we'd have all new problems!"

Sincerely,
--Eljay

RE: Exception Specifications

[Martin York]

 

Hope I am not stepping into a religious war but.

I think the general consensus is that it is not a good idea to use
exception specification on functions/methods. My main objection is that
I do not want an unexpected exception to make the application exit with
a call to 'unexpected()'.

I think Hurb Sutter summaries the point well (an more eloquently that I)
on this page:
http://www.gotw.ca/gotw/082.htm (see section 4)


Martin.



-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Perry Smith
Sent: Wednesday, December 06, 2006 9:27 AM
To: MSX to GCC
Subject: Exception Specifications

I believe I saw in some of the boost libraries that they do not use
exception specifications because some compilers produce slower code.

I'm considering adding exception specifications to most/all of my
functions -- mostly for my own sake.  But I'm wondering how it will
affect the compiler's generated code.  (i.e. if it is going to affect
performance, I can put the exception specifications in comments just as
easily).  I'm currently using gcc 4.0.2.

Thank you,
Perry Smith ( pedz@easesoftware.com )
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems