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


On 12/03/2012 10:53 AM, Michael Meeks wrote:
On Fri, 2012-11-30 at 18:53 +0100, Lubos Lunak wrote:
On Friday 30 of November 2012, Stephan Bergmann wrote:
I'm not sure this is a good move.
...
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.

        I'm convinced it is a benefit :-) - and it's interesting; there have
been a string of decisions in the past where we have decided to go for
more readable code over (IMHO) gross verbosity:

-       rtl::OUString( RTL_USTRING_VERYLONGNAME( "foo" ) )
+       "foo"

        to me is a -massive- improvement in readability. More minor ones are:

-       rtl::OUString
+       OUString

        Many of these have been resisted with the same "no benefit" argument. I
believe that every redundant token we can clarify, and simplify makes
reading and getting into the code much easier for new people. Hackers
have to spend tons of their time reading and un-tangling code, so
maximum readability is key.

I agree that the string literal clean-up is a big win, makes it much more pleasant to read and write code, and that I was wrong in considering it syntactic sugar that would likely not be worth the effort.

However, in this case, I argue that leaving the dynamic exception specifications in does have a benefit, in a part of the original mail that got elided.

        In my view the inevitable line-wrapping / 80 char bustage that huge
long exception descriptions bring brings a significant impairment of
readability. What should read as a simple interface implementation (and
to be fair looks reasonably clean and readable as IDL) gets turned into
something much fouler in the header & impl. The css:: mangling helps in
some minor way with this - but I feel it is far better to hide as much
as humanly possible of that duplicate guff.

IMO, the duplication is beneficial here. Just as we duplicate, say, a method's return type and parameter types from the UNOIDL specification into the C++ implementation -- and not only because we are technically forced to, but also because it makes the resulting C++ code so much more comprehensible.

Abbreviating "com::sun::star::" to "css::" and folding explicitly listed subclasses of RuntimeException can likely go a long way to reduce accidental complexity while keeping the necessary complexity evident.


  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.

        Quite. Personally - I'm deeply unconvinced that we can afford to have a
code-base where all manner of unexpected side-effects remain un-checked
at compile-time etc. The "only call methods that throw exceptions
mentioned above" criteria is (to me) far too opaque to have any
reasonable chance of reviews and newbie implementers from following it -
worse manual checking of that sort of tedious detail, even if it is done
is highly error prone: and I suspect is done only one way. Who - when
changing a function checks all call-sites of it to see if they declare
that exception ? ;-)

Where does the "only call methods that throw exceptions mentioned above" criterion come form? It misses a fundamental part of programming with exceptions, namely the necessity to match exceptions thrown by a function's implementation to the function's interface.

Stephan

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.