On 2021-09-04 7:08 a.m., Niels Sascha Reedijk wrote:
> Based on the recent discussion which also piqued my own curiosity, I
have played around with exceptions a little bit and I rewrote the
experimental proposal (and the documentation around it). You can find it
here: https://github.com/nielx/haiku-netservices-rfc/tree/exceptions
>
> In section A.3 I express my view on how and when to use exceptions in
a public API.
>
> My impressions so far:
> * I think rich error objects are preferred to status_t or equivalent
generic errors. Independent of the error mechanism, it does make sense
to add more information about errors, and to use the C++ type system to
make that flexible.
> * I like exceptions as the transport mechanism for errors. It
simplifies the public API a lot, because it removes the need for
Expected<T, E> return values and factory methods (because now
constructors can fail). I understand the issue with discoverability, but
at the same time it is a mindset issue. Like you have to train a dev to
handle status_t error codes, you need to train them to be wary of
exceptions for any method or function that is not defined as noexcept.
Good point about using exceptions to transport errors. However, I'd
like an even richer object than the BError one you have, which is just
an error code and a string. Though at least it's a std::string (not
BString?) so it can be grown (or at least sprintf'd to), and thus can
have a variable error message with some context. Like I said before, a
stack of them would be more useful to everyone so you could see the high
level error explanation and drill down to the lower levels.
Same thing for std::exception, it just has a single what() string. Also
there's the awkwardness of having separate classes instead of error
codes (https://en.cppreference.com/w/cpp/error/exception), because
that's what the exception mechanism can test for. Though does testing
for subclasses make up for that when you want to check an error in
code? Think of trying to create a file and getting a directory not
found error, then creating the directory if that was the error. Easy
with numerical codes. More awkward with exception class testing.
Though come to think of it, you can represent the error string stack in
memory as an appended single string, by storing everything as ASCII,
with new lines separating the error layers, and tabs separating the
error fields (error code, description, source file, source line). Then
if you want the whole thing as a string, just dump it out. While a GUI
would just extract the top level error explanation, with the option to
drill down or list the other layers of error. Programs would have a way
to quickly get the top level error code.
Yes, exceptions could work for me, with an even richer error object to
get in my error stack functionality.
- Alex
