Dynamic Exception Specifications

[Michael Stahl]

On 18.01.2017 14:03, Stephan Bergmann wrote:
> For better or worse, dynamic exception specifications (the "throw (ex1, 
> ex2, ex3)" part of function declarations) were deprecated in C++11 and 
> will be removed from the language entirely in C++17.  (The new 
> alternative being 'noexcept'.)
> 
> Consequently, (current trunk builds towards) GCC 7 issues a -Wdeprecated 
> warning for each dynamic exception specification it encounters.  Which 
> for us means that we'll need to come up with a plan for the exception 
> specifications across the LO code base, short of bluntly disabling all 
> kind of -Wdeprecated for GCC 7---which is hardly what we want to do 
> going forward.
> 
> There are four cases to consider:
> 
> A  URE interface include files.
> 
> B  Generated UNO API include files.
> 
> C  "Plain" LO internal code.
> 
> D  "External" code where LIBO_INTERNAL_ONLY is not defined: SDK 
> examples, extension code.

we already do release builds with -fno-enforce-eh-specs, while MSVC
just ignores the exception specifications, and only --enable-dbgutil
turns them on with GCC and clang, so there should be no difference for
release builds.

currently the exception specifications effectively serve as an assertion
mechanism where an API implementation fails the assertion if it throws
an exception that it isn't documented to throw.

this happens from time to time, so i wonder what replacement you have in
mind for the current 1000s of assertions to quickly and easily detect
such bugs.

> Instead of coming up with new macros (after we've successfully removed 
> SAL_THROW in the past) to hide dynamic exception specifications behind, 
> my proposal is to remove them completely from all of the code (on 
> current master towards LO 5.4).