Re: [API] Some more cleanup ideas

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