> I mean, the proposal is about an extensible error system for all libraries
that want/need their own error codes, and at the same time interoperate
with code returning errors of their own. It's not about libhttp in
particular,
it's just that libhttp exhibits this pattern, much like many other places
in HelenOS.
What libhttp is doing with error codes is wrong. It should be fixed instead
of trying to bend errno_t to deal with it. The fact that other libraries are
possibly doing the same thing doesn't make it less wrong.
-Jiri
---------- Původní e-mail ----------
Od: Jiří Zárevúcky <[email protected]>
Komu: HelenOS development mailing list <[email protected]>
Datum: 6. 12. 2017 22:16:27
Předmět: Re: [HelenOS-devel] [RFC] Locally extensible error returns
"On 6 December 2017 at 22:04, Jiří Zárevúcky <[email protected]>
wrote:
> On 6 December 2017 at 21:20, Jiri Svoboda <[email protected]> wrote:
>> Hi Jiri,
>>
>> well this is maybe the least important problem that libhttp has. Why don'
t
>> you just fix libhttp so that each of its functions either returns errno_t
or
>> an http_error_t that is completely separate type from errno_t?
>>
>
> Because that would be more difficult, as well as less beneficial in
> the long run.
> But of course, it's a possibility.
>
I mean, the proposal is about an extensible error system for all libraries
that want/need their own error codes, and at the same time interoperate
with code returning errors of their own. It's not about libhttp in
particular,
it's just that libhttp exhibits this pattern, much like many other places
in HelenOS. It's not a solution for libhttp, it's a solution for the bugs
that
inevitably crop up when code mixes calls to functions with differing error
reporting behavior. Fixing those bugs is basically all I've been doing for
the past two days.
> -- jzr
>
>> Regards,
>> Jiri
>> ---------- Původní e-mail ----------
>> Od: Jiří Zárevúcky <[email protected]>
>> Komu: HelenOS development mailing list <[email protected]>
>> Datum: 6. 12. 2017 16:19:24
>> Předmět: [HelenOS-devel] [RFC] Locally extensible error returns
>>
>> Hello,
>> For context: I've been working on fixing our errno.h use for the past
>> two days. It's going very well, I'll probably be done by tomorrow, and
>> I'll write a blog post about the entire process after I'm finished.
>>
>> The issue I'm facing now is simple: libhttp uses errno.h error codes,
>> but also defines its own bunch of error conditions, mixing them with
>> returns from libc functions. Obviously, this is not ideal. Such errors
>> can start conflicting with others on a later date, without any
>> indication that something is wrong, and it's not possible to just use
>> strerror() on such a return value, or return it from an interface that
>> expects libc error codes (for example, imagine a HTTP data transport
>> abstracted as a pipe -- such code would need to translate
>> HTTP-specific error codes, but there is no indication on type level
>> that that's necessary).
>>
>> That much for context. I thought about possible solutions, and this is
>> the best I came up so far. Instead of explaining in words, simplified
>> example of code:
>>
>> ----
>>
>> // libc header
>> typedef struct {
>> const char *name;
>> const char *description;
>> } error_t;
>>
>> extern const error_t *E_NOMEM;
>> extern const error_t *E_IO;
>> ----
>> // libhttp header
>> extern const error_t *HTTP_E_HEADERS;
>>
>> ----
>> // libc object file
>>
>> static error_t _NOMEM = { "E_NOMEM", "Out of memory" };
>> const error_t *E_NOMEM = &_NOMEM;
>>
>> static error_t _IO = { "E_IO", "IO failed" };
>> const error_t *E_IO = &_IO;
>>
>> ----
>> // libhttp object file
>>
>> static error_t _HEADERS = {"HTTP_E_HEADERS", "HTTP: Failed processing
>> headers" };
>> const error_t *HTTP_E_HEADERS = &_HEADERS;
>>
>> ----
>> // user
>>
>> const error_t *err = http_func_1(...);
>> if (err == HTTP_E_HEADERS) {
>> // process error
>> } else if (err == E_IO) {
>> // process other error
>> } else {
>> // process all other errors
>> fprintf(stderr, "Failed http operation: [%s] %s\n", err->name,
>> err->description);
>> exit(1);
>> }
>>
>>
>>
>>
>>
>>
>>
>> What do you think?
>>
>> -- jzr
>>
>> _______________________________________________
>> HelenOS-devel mailing list
>> [email protected]
>> http://lists.modry.cz/listinfo/helenos-devel
>>
>>
>> _______________________________________________
>> HelenOS-devel mailing list
>> [email protected]
>> http://lists.modry.cz/listinfo/helenos-devel
>>
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
"_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
