On Thu, 2 Sept 2021 at 06:54, Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
wrote:
Hi,
I decided to split this into a separate thread.
On Wed, Sep 1, 2021 at 3:41 PM Mr. waddlesplash <waddlesplash@xxxxxxxxx>
wrote:
with the legacy error handling without exceptions and using status_t and
On Wed, Sep 1, 2021 at 2:32 AM Niels Sascha Reedijk
<niels.reedijk@xxxxxxxxx> wrote:
Also agreed. Having said that, unless the final decision is to stay
invalid objects, it seems likely that we will end up in a situation where
there would be legacy error handling (in the older kits) and modern error
handling (in newer kits).
I think it is worth noting at this point that the major error handling
paradigms of newer languages, like Rust, are pretty much
exception-free (I guess Rust has "recoverable panics" but they are not
at all intended to be used like exceptions), and instead have error
handling strategies that are functionally like status_t returns but
with more syntactic sugar attached.
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.
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 don't think error codes are necessarily much better.
(1) In terms of discoverability, you could say that when a
function/method returns an error code, it does signal that an error
may occur. However, our convention is to use the `status_t` type, and
we often forward error codes that may have occurred several calls down
from the API call that the user uses. Thus in reality, the potential
clarity of the error code is not much better. In fact, I would argue
that there is no difference between the discoverability of an error
code path between a function that explicitly returns a `status_t` or a
function that is not decorated with `noexcept`. Both can fail!
(2) The cost of exceptions is relative, we no longer live in the 90s
and we have a lot more resources now. Plus, adding checks for if
(status != B_OK) might be cheaper but it is not free.
(3) Modern C++ allows you to do a lot more with scoped objects. If
RAII principles are adhered to, that means that you can write
exception safe code that will not put objects in an inconsistent state
or will leak memory.