Dynamic Exception Specifications

[Stephan Bergmann]

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.

Thoughts?