Re: Dynamic Exception Specifications

The below is done, meanwhile.  Two items to note:

* Consequently, no longer necessary #includes have been removed from 
cppumaker-generated files, which may cause 3rd-party code (or any LO 
code I didn't manage to compile myself---but I tried hard) to no longer 
compile (to fix, add the missing #includes to the client code).

* Only after doing the automatic conversion did I discover now that 
dynamic exception specifications on deallocation functions should have 
been replaced with 'noexcept(false)' instead of just dropping them. 
However, I think there were no such in our code base to begin with.

On 01/18/2017 02:03 PM, 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.
>
> 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).
>
> For 3rd-party code interfacing with A+B, that change should be backwards
> compatible.
>
> For anything but dtors, removing the dynamic exception specification
> implicitly makes the function nothrow(false).  For dtors, the dynamic
> exception specification would be replaced with an explicit
> nothrow(false).  An empty 'throw ()' will be reclassified as not a
> dynamic exception specification in C++17 (and GCC 7 doesn't emit
> -Wdeprecated for it); occurrences of that will remain unchanged.
>
> I'd do the change in the following steps:
>
> 1  Remove dynamic exception specifications from A+C (with the help of a
> rewriting Clang plugin).
>
> 2  Build the D code to demonstrate that changing A is indeed backwards
> compatible.
>
> 3  Remove dynamic exception specifications from B (by modifying cppumaker).
>
> 4  Build the D code to demonstrate that changing B is indeed backwards
> compatible.
>
> 5  Remove dynamic exception specifications from D.
>
> Now, knowing what kinds of exceptions a function is intended to throw is
> useful information, arguably part of the function's interface even.
> Removing dynamic exception specifications would thus remove useful
> documentation in many cases.
>
> Therefore, I'd introduce a preliminary step
>
> 0  With the help of a Clang plugin, find functions with dynamic
> exception specifications for which Doxygen-style documentation is
> missing, and add such @throws clauses.
>
> I'd not do that step 0 for B (those generated files are not really
> human-friendly anyway, and the information is readily available in the
> corresponding UNOIDL files), and also generally restrict it to
> non-overriding functions.