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...) _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice