Re: [API] Some more cleanup ideas

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.

Stephan