[API] Some more cleanup ideas
sbergman at redhat.com
Fri Nov 30 08:01:12 PST 2012
On 11/29/2012 06:42 PM, Thorsten Behrens wrote:
> Stephan Bergmann wrote:
>> Right, forgot about the Clang case. So that would mean keeping
>> SAL_THROW non-deprecated, making it a nop with Clang
>> --disable-dbgutil (but making it a non-nop for GCC generally), and
>> changing the cppumaker-generated headers to use SAL_THROW.
> So the change meanwhile got committed as
> 0295bd6b3f21dd648af6145ca23d90467f3cec73, and while discussion was
> ongoing here & on irc, I went the "bin exception specs entirely"
> route for c++.
> I concede there's potential debugging utility in having compilers
> generate runtime checks for exception specs in dbg_util mode, I
> wonder though if this is worth the mess we'd generate.
> With SAL_THROW & exception specs on api headers removed, there's a
> very nice & substantial cleanup task possible subsequently, that
> removes it from all implementation methods, too.
I'm not sure this is a good move.
To be able to programmatically react to an exception raised by a UNO
method (which is the raison d'être of non-runtime UNO exceptions), the
specification of that method must document the method's behavior with
respect to raising that exception, and any implementation of the method
must adhere to that specification. However, with that part of a UNO
method's interface moved out of sight of a programmer writing a C++
implementation of that method, I fear that adherence to specification
will degrade in practice. And that negatively affects an area where we
do not shine anyway: reaction to errors. (Which is arguably a tricky
area to begin with, but so would probably benefit more from increasing
awareness and tooling than from reducing them.)
There is indeed a trend in C++ to move away from dynamic exception
specifications, but I see none of the problems that motivated that trend
affecting us in this specific case.
The compiler-induced checks for unexpected that are inherent to dynamic
exception specifications and cause space/time overhead can be addressed
in production code with -fno-enfore-eh-specs or similar, or could be
addressed with SAL_THROW where "or similar" does not work.
There is one concern with the old scheme, namely that exceptions like
std::bad_alloc cannot pass out of UNO method implementations, so it is
not possible to programmatically react to some isolated operation
running out of memory, say. However, for the latter to work much more
preparation would be needed (like all the involved functions sporting
strong exception guarantees), it is unclear whether those relatively
coarse-grained UNO method invocations would not lie outside such
programatic catch-and-handle areas anyway, and this could also be made
to work with the old scheme, by consistently adding std::exception or
similar to the dynamic exception specifications.
Which leaves us with the benefit of shorter, less visually cluttered
declarations of C++ functions. But, as I argue above, I am not sure
that is an overall benefit at all.
More information about the LibreOffice