Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.