Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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.

 It's been pointed out to me that I'm written as the one to do this change in 
the LibreOffice4 wiki page. Which was a bit of a surprise to me, given that I 
don't feel very strongly one way or another (the only thing I felt strongly 
about a while back was that I didn't want Clang to be the only compiler where 
the exception specifications actually did anything).

 Digging in the wiki history, it was Thorsten who added the items related to 
exception specifications removal, and the link to the C++ article is from 
Bjoern. I did move the item to the list of things that actually will be done 
and added my name to it while doing so; my memory is a bit hazy on it, but I 
think I somehow mistakenly assumed the item was agreed upon and it probably 
felt like a good thing to try the Clang plugins on. Well, or at least that's 
the best explanation I can come up with now, I don't remember.

 That said, from what I can tell, Stephan is correct on the technical details. 
The problems seen with exception specifications, such as making the app fall 
flat on its face in case of a problem or being troublesome with templates, 
are of little or no concern in dbgutil build. In product builds it can be 
turned off for GCC, MSVC up to at least 2010 doesn't seem to give a damn, and 
Clang is probably no big deal to handle somehow if seen worth the effort.

 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.

-- 
 Lubos Lunak
 l.lunak@suse.cz

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.