Skip to content

[Rcpp-devel] Code Refactor Proposal: exception specifiers

3 messages · Dirk Eddelbuettel, Darren Cook

Darren Cook
# 
I had a poke around the Rcpp code today, and noticed exception
specifiers are used quite widely. I wondered if these were used with
full knowledge of their pros/cons in C++, or if they were put there by
someone coming from Java?

Some arguments against their use:
 * Item 14 in Meyer's More Effective C++
  (the Session destructor example was enough to convince me.)

 * Herb Sutter's "A Pragmatic Look at Exception Specifications":
   http://www.gotw.ca/publications/mill22.htm

 * C++0x has deprecated them.
  (it introduces "noexcept" as a better throw(), but not available until
g++ 4.6)

Darren
Dirk Eddelbuettel
#
On 16 August 2011 at 11:45, Darren Cook wrote:
| I had a poke around the Rcpp code today, and noticed exception
| specifiers are used quite widely. I wondered if these were used with
| full knowledge of their pros/cons in C++, or if they were put there by
| someone coming from Java?

You will get a firm "oh quite possibly" for that.  :)
 
| Some arguments against their use:
|  * Item 14 in Meyer's More Effective C++
|   (the Session destructor example was enough to convince me.)

Hm, I don't have a copy handy right now, only his first and the STL one.
 
|  * Herb Sutter's "A Pragmatic Look at Exception Specifications":
|    http://www.gotw.ca/publications/mill22.htm

I glanced at that, thanks for the pointer.
 
|  * C++0x has deprecated them.
|   (it introduces "noexcept" as a better throw(), but not available until
| g++ 4.6)

Right now I feel like 'wait and see'. We are pretty strict about suppressing
g++ warnings and errors but this may not get addressed to g++ 4.7 or
whichever warns about it.  All in all it seems more like a stylistical issue.

Thanks for the heads-up.

Dirk
Darren Cook
# 
The whole Exceptions section (units 9 to 15) is worth a read.
I wasn't proposing introducing noexcept at this stage; I was proposing
stripping out all the throw() specifications. They are very unlikely to
be of positive benefit, but can negatively affect performance.
(You would expect them to be a compile-time check, that has no effect on
run-time (*), but in reality they are the opposite: they are not used at
compile-time, but are used at run-time.)

Darren

*: Which I think is how they work in Java? (My java is getting rather
rusty.)