[API] Some more cleanup ideas
Stephan Bergmann
sbergman at redhat.com
Thu Nov 29 05:05:53 PST 2012
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
More information about the LibreOffice
mailing list