Hi,
quoting myself:
>>> 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?
So, if you don't like errno_t, the other option is the libhttp-specific
error, e.g. http_error_t. right?
When you choose to make a special error enum, you probably have put a lot of
care into the design of an API and the ways it can fail... which I'm not
sure is the case of libhttp... But in any case either of pure errno_t or
some kind of http_error_t could be used here.
We can have a more general/philosophical chat about handling errors at the
meeting. I should probably write some article on my theories of error
handling since I've given the subject a significant amount of thinking time.
Having some basic guidelines for HelenOS might be useful (beyond mimic what
you see) but then we would have to agree to agree first :-)
Cheers,
Jiri
---------- Původní e-mail ----------
Od: Jiří Zárevúcky <[email protected]>
Komu: HelenOS development mailing list <[email protected]>
Datum: 7. 12. 2017 16:14:42
Předmět: Re: [HelenOS-devel] [RFC] Locally extensible error returns
"On 7 December 2017 at 12:12, Jiri Svoboda <[email protected]> wrote:
>> 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.
I lost you. This has little to do with errno_t. Are you saying every
library should limit itself to <errno.h> constants?
> -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
>
_______________________________________________
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
