On 30/11/12 18:53, Lubos Lunak wrote:
> On Friday 30 of November 2012, Stephan Bergmann wrote:
>> On 11/29/2012 06:42 PM, Thorsten Behrens wrote:
>>> 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.
> ....
>> 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.
> So, in practice, the specifications in our case are like writting out
> asserts
> in the code, and the only questions that there should be are whether it makes
> sense to have such asserts and whether they are worth the code clutter.
so... following the above reasoning i have just re-enabled the exception
specifications with eb0cfb3bf220892e4885945452930790f5e22000; they are
written only in an --enable-dbgutil build.
what is still missing then is a macro for use in the API implementations
that expands to nothing unless --enable-dbgutil is set; presumably a
cleanup to use such a macro everywhere should be done together with
replacing the ::com::sun::star in the exception specs with ::css, which
should make the clutter a bit less annoying.
... what i'd really like to have though is a C++ keyword ("override",
say; "pony" would work for me too) with semantics of "just use the same
exception specification as the base class method" ... plus "error if
there is not actually a base class method with that parameter
signature", while we're at it.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
