On 6 December 2017 at 22:04, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote:
> On 6 December 2017 at 21:20, Jiri Svoboda <jirik.svob...@seznam.cz> 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 <zarevucky.j...@gmail.com>
>> Komu: HelenOS development mailing list <helenos-devel@lists.modry.cz>
>> 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
>> HelenOS-devel@lists.modry.cz
>> http://lists.modry.cz/listinfo/helenos-devel
>>
>>
>> _______________________________________________
>> HelenOS-devel mailing list
>> HelenOS-devel@lists.modry.cz
>> http://lists.modry.cz/listinfo/helenos-devel
>>
_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
