Exception specifications on functions useless?

[Michael Stahl]

On 20/03/12 22:50, Lubos Lunak wrote:
> 
>  Hello,
> 
>  I've just found out that exception specification on functions in LO have been 
> just pretty comments, for about 10 years.
> 
>  Just to make sure what I'm talking about, it's the throw() in e.g. this
> 
> void foo( int a, void* b ) throw( css::uno::RuntimeException );
> 
> which says what exceptions a function can throw.
> 
>  I found out by compiling LO with Clang, running it and having it crash where 
> gcc-compiler version had no problem. Stephan Bergmann and repo history 
> revealed that in 2001 -fno-enforce-eh-specs was added to gcc's flags, turning 
> off code generated that ensures these specifications are actually followed 
> (and MSVC has reportedly never cared).

it used to work like this:
- MSVC apparently doesn't support enforcing the exception
  specifications as mandated by the C++ standard at all
- for GCC they were explicitly disabled, at least on Linux
- for SunStudio they were actually enforced and incorrect ones lead to
  immediate abort via std::terminate (which is why i have fixed
  a lot of incorrect exception specifications in the code over the
  years, working mostly on Solaris)

> Clang does not have the option. I've 
> already actually fixed the problem (in 
> vbahelper/inc/vbahelper/vbaccesshelper.hxx) and it appears the specifications 
> somehow magically haven't rotten, as now LO runs fine for me (as far as I can 
> say, I can't test everything).
> 
>  That however brings up the question of what the specification are for in the 
> codebase. The 'Deprecated Exception Specifications, Added noexcept' part of 
> http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ 
> is quite interesting read, the summary is:
> 
> - the specifications enforce that disallowed exceptions are not thrown at 
> runtime, adding code to each such function to check it, thus actually making 
> the performance worse
> 
> - boost, and pretty much everybody else it seems, do not consider it worth the 
> hassle of specifying what a function may or may not throw, except for 
> flagging a non-inline method as not throwing any exception at all as a means 
> of optimization for places where such functions are called
> 
> - C++11 deprecates it and instead introduces a noexcept keyword which forbids 
> the function to throw anything
> 
>  I'm not strongly biased either way, but what we have right now are really 
> just pretty comments on functions. I think we should either say that we use 
> the specifications, in which case -fno-enforce-sh-specs should not be used at 
> least in debug builds, or we can say we follow the C++11/Boost/etc. trend and 
> not use them, in which case we can have one macro for portable way of saying 
> noexcept and have an EasyHack for removing the other specifications. BTW, it 
> should be also noted that SAL_THROW() expands to nothing with gcc.
> 
>  Opinions on this?

exception specifications in C++ are pretty useless because they are only
checked at runtime, not statically, and the only handling that is
realistically possible for violations is to abort the program.

it may be a good idea to annotate functions that are guaranteed not to
throw because that could enable some micro-optimizations from the C++
implementation, but other than that it doesn't make sense for us to use
these.

for the case where it is a good idea to check exceptions (e.g. Java UNO
bridge, which cannot throw exceptions to the Java side that are not
declared on the interface), a runtime catch-all check should be
sufficient also.

but i wonder if there is any compatibility concern here; i'd be more
comfortable if we only removed the exceptions specifications for LO4 and
not earlier.

(now i'll actually go read the article you linked...)