Re: [API] Some more cleanup ideas

On 11/29/2012 12:37 PM, Michael Stahl wrote:
> On 29/11/12 01:54, Thorsten Behrens wrote:
> >   * cleansed cppumaker of dead code, RTL_CONSTASCII verbosity, and
> >     writing out exception specs
>
> iirc we want to remove C++ exception specifications for production code
> because they don't make sense there - but would it make sense to keep
> them in --enable-dbgutil mode?  could be useful for debugging... after
> all if an exception that isn't documented is thrown that's still a
> violation of the API contract.

Just noted that solenv/gbuild/platform/com_GCC_defs.mk already does 
that, setting -fno-enforce-eh-specs unless --enable-dbgutil.

solenv/gbuild/platform/com_MSC_defs.mk strangely uses -EHa (catching SEH 
exceptions in addition to C++ exceptions) instead of -EHs (catching just 
C++ exceptions) or even -EHsc (in addition, assume C functions to never 
throw).  I don't know whether MSC has a switch these days similar to 
GCC's -fno-enforce-eh-specs (i.e., to avoid emitting code that catches 
unexpected exceptions and diverts to std::unexpected) -- IIRC it 
traditionally behaved like that per default, but I think that Standard 
violation got fixed eventually?

The above does not match well with SAL_THROW as currently defined in 
sal/types.h:  The latter expands to nothing for GCC and to throw (...) 
for MSC.  The intention behind that was the same as what has been 
discussed above, to avoid the additional unexpected-checks emitted by 
the compiler in production code (likely GCC did not have 
-fno-enfore-eh-specs back then, Sun CC had to be catered for too, and 
MSC was definitely always violating the Standard back then by 
effectively ignoring any exception specifications).  So I think it makes 
sense to deprecate SAL_THROW in favor of plain exception specifications. 
 (So this obsoletes my other mail asking to "keep the exception 
specifications as SAL_THROW comments.")

And to keep us honest, it probably makes sense to keep exception 
specifications in cppumaker-generated headers after all.  The 
implementations of those functions need to adhere to the corresponding 
UNOIDL method raises-clauses anyway (when interacting with other UNO 
environments, or even with old C++ UNO code), and having them checked at 
runtime in --enable-dbgutil builds helps identify design bugs in the API 
(see e.g. <https://bugs.freedesktop.org/show_bug.cgi?id=57611#c6> 
"report builder design mode CRASH on change FixedLine height to zero").

> > There remain the following open questions:
> >
> >   * should we keep ~MyClass() {} throw() - or rather have just one
> >     single proper virtual ~XInterface() {} throw in the base class
> >     (note the missing virtual all over the place) - or bin all
> >     exception specs unconditionally?
>
> "throw ()" on a destructor does not hurt imho - it is not allowed to
> throw anything in practice...
> i'm not aware of any problems by relying on default dtor in derived
> classes, but i'm sort of a mere user of C++ so what do i know anyway...

The explicitly mentioned dtors in derived classes are there to "avoid 
warnings about virtual members and non-virtual dtor" (made necessary by 
the design bug of not having a virtual dtor generated for XInterface).

Stephan