Exception specifications on functions useless?
mstahl at redhat.com
Wed Mar 21 03:37:26 PDT 2012
On 20/03/12 22:50, Lubos Lunak wrote:
> 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
> 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
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
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
(now i'll actually go read the article you linked...)
More information about the LibreOffice