[haiku-development] Re: Error Handling (was: Re: Plan for NetServices Kit (v2))
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 15 Sep 2021 09:16:22 +0200
Hi Niels,
Am 15.09.2021 um 08:51 schrieb Niels Sascha Reedijk:
My position currently is that I am in favor of exceptions as the error
handling mechanism, because (1) it is a fundamental language feature
with rich support in the language and standard library, (2) many of
the (perceived) drawbacks of exceptions in (pre-?)C++98 are mitigated
by more modern languages constructs and (3) I actually have an
aesthetic preference. I am also (4) not convinced by the argument that
the status_t needs to persevere because of the argument of
consistency, as I think there should be space to deviate and
experiment, especially in non-legacy kits. Nor am I convinced (5) by
the argument that exceptions are inherently undiscoverable, as the
noexcept qualifier on API methods is actually expressing which methods
might throw exceptions and which ones do not.
The only thing I can try to argue about is (4):
For me, developing with a consistent framework is a huge plus.
Everything feels, and works in the same way. Your code is clear, and
easily readable, as everything follows the same basic principles.
That's what's making working with a framework a nice, and pleasant
experience.
The Be API was largely consistent to use, and, as you may have heard, is
apparently a joy to use. Of course, it's not just consistency, but also
simplicity, and clarity. But consistency delivers a big part of that
whole experience.
If you have ever worked with Java Swing, you know that missing
consistency, even in tiny details can be extremely annoying, and lead to
subtle, and not so subtle bugs.
That said, this is *not* an argument against change. If you want to play
around with exceptions in the NetServices Kit, just do it. If most
people like it, it may become the basis of our future API paradigm.
It may also be considered as odd, and not acceptable. Then it might have
to be reworked to follow some different ideas.
But we'll never know if you don't try.
Not having a consistent API is not a good idea, but if you notice that
this new way is actually better than before, it would still make sense
to move into this direction, and aiming for consistency in the future,
again, kit by kit.
Our current API will need to be reworked a lot, just for security
purposes (for instance, everbody is allowed to write to any ports), and
it would be stupid not to try something new, even if we're all content
with the current API spirit.
Bye,
Axel.
Other related posts:
