Re: [API] Some more cleanup ideas

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.