[haiku-development] Re: Error Handling (was: Re: Plan for NetServices Kit (v2))
- From: "Mr. waddlesplash" <waddlesplash@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 1 Sep 2021 15:28:32 -0400
On Wed, Sep 1, 2021 at 2:54 PM Niels Sascha Reedijk
<niels.reedijk@xxxxxxxxx> wrote:
I think this might be one of the more contentious topics, and I
actually expected your opinion to be more widely shared, which is why
I introduced the Expected<T, E> return type which is modeled after the
std::expected proposal [1] for standard C++. This type comes very
close to Rust's Result<T, E> type.
Yes, I am still not sure how I feel about this idea, but I do like it
more than exceptions at least. :)
Having said that... I am not against exceptions, but I do think it is
a feature that needs to have some very clear rules about how and when
they are used in the public API.
The main arguments against exceptions are:
(1) discoverability: there is no inherent language feature that makes
you make exceptions discoverable, so you would have to resort to
documentation or practises that keep the definition of exceptions and
where they can occur close together.
(2) speed: stack unwinding is expensive.
(3) safety: there are challenges writing code that cleanly handles exceptions
I would add a (4): it makes error handling where you want to do
different things based on where a failure occurs rather tricky, and
even when it is possible, it makes code much uglier to throw try/catch
in all over the place as compared to if (.. B_OK) {}, or Rust's
unwrap() or chaining operators. To me, the code readability aspect is
as much or even more of a problem than the discoverability or safety
problems.
I don't think error codes are necessarily much better.
The (nodiscard) attribute can help here, it mitigates discoverability
(the compiler simply will not let you discard the result silently),
and that leaves only "safety". But I think in most cases where a
status is improperly ignored, you simply would get nothing (e.g. you
requested a download, but it failed, so you have an error status and
no data.)
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'll page you on IRC.
-waddlesplash
Other related posts:
