[haiku-development] Re: Error Handling (was: Re: Plan for NetServices Kit (v2))
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 03 Sep 2021 07:29:59 +0000
I'm not sure helpers are very useful. Usually you will need to handle each
error specifically, and
is_posix_error does not tell you much. It would lead to error messages in
applications like
"Some POSIX error happened", which is even worse than what we have now. We
already have some
constants
available in https://git.haiku-os.org/haiku/tree/headers/os/support/Errors.h ;
(B_GENERAL_ERROR_BASE,
B_MEDIA_ERROR_BASE, ...) and I've never seen them used except for defining
the error codes?
You could probably have done something like B_HTTP_ERROR_BASE + 500, etc.?
And at the very least,
you'd get something more meaningful with these handled in `strerror()`. It
was just a thought. When
looking at a command line app like pkgman in the contrived example, it would
be a bit more
meaningful to the user than some of the current generic status_t errors we
currently get. Just
throwing it out there in regards to status_t itself.
HTTP replies already include a number and an user readable message ("200 OK",
"404 Not found",
"500 Internal server error", etc). You don't want to drop the string sent by
the server and replace
it with a generic strerror one.
And the protocol can use any error number. What if a server responds with one
you don't know?
For example "418 I'm a teapot"? (that's not part of the HTTP spec, but it is
specified in ana
april's fool RFC and implemeted by some servers). Would that translate to
B_HTTP_ERROR_BASE + 418,
and then be translated by strerror to "Unknown HTTP error 418"? That's not much
help to users.
I think what's needed for these cases is a higher level object to represent the
error. In C++
exceptions, instead of just an integer constant, you get a string with an error
message in
the std::exception class. I think the BError class that nielx suggested earlier
would achieve
something similar. The downside is that handling that is a bit more annoying
than handling
a simple constant, especially in the lower level parts of the OS (you need to
allocate memory
for the string, either you do it on the stack and it's slow because the object
will need to be
copied several times, or you do it on the heap and you can't use this object to
handle out of
memory errors, for example). Which means in the end you probably have a mix of
integer based
status_t and BError objects...
--
Adrien.
Other related posts:
