[haiku-development] Re: Error Handling (was: Re: Plan for NetServices Kit (v2))
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 2 Sep 2021 10:49:16 +0200
Am 01.09.2021 um 21:28 schrieb Mr. waddlesplash:
There is also the argument that we should not introduce a new error
handling paradigm in a new and experimental kit. I guess that it makes
some sense to do all the experiments at once, but I think if we are
aiming for stability here, and reengineering a kit that already does
some things acceptably that we need to do more things well, then there
is a serious argument that we should avoid too many experiments, and
do them separately / later.
I think that's actually a good argument against this kind of API changes
for now.
The counterargument would be: you have to start somewhere, and it's more
work to transform an existing code base (with likely less consistent
outcome), than to follow a new paradigm from the start.
As I mostly do Java development these days, I think that I can fairly
say that there is no huge advantage for either way of handling errors
IMO. They both have their issues, and they both have their strengths (in
the case of exceptions, it's much easier to transport the actual cause
of an error to higher levels). Just mixing both ways is annoying, and
should be avoided IMO.
Since all of our code base uses status_t, I would not have any problem
with us just following that particular decision forever (unless new
arguments come to surface). And maybe even change the Package Kit to
follow suite. Consistency is pretty much the highest goal in API
development IMO.
Since we plan to maybe break source compatibility at some point, maybe
by introducing another set of libraries that you can use side by side
for a while, that would be a point where we could, and should, revisit
all API related decisions.
That would be my 2 cents.
Bye,
Axel.
Other related posts:
