I understand your concerns. My key point I think is that this is a 'big'
question.
1) There are many aspects to consider when choosing the right option, the
ones you mention are just a few of them
2) People could evaluate based on both technical and esthetical/emotional
grounds
3) There quite a few possible options how to implement it
4) Any option that requires everybody to change from the status quo has a
huge impact on 90% of the code. If the change required is non-trivial, it
would have to be introduced gradually and could take years to implement or
never be finished at all.
That's why my personal approach so far was to mostly preserve the status quo
where we have some prominent interfaces that introduced their errors to
errno_t and I have been mapping all my errors to a few of the very generic
Exxx codes (ENOMEM, ELIIMIT, ENOENT, EINVAL). In one case I opted to create
a separate enum type (internally in TCP) but that was for a special reason.
Regards,
Jiri
---------- Původní e-mail ----------
Od: Jiří Zárevúcky <[email protected]>
Komu: HelenOS development mailing list <[email protected]>
Datum: 8. 12. 2017 21:28:35
Předmět: Re: [HelenOS-devel] [RFC] Locally extensible error returns
"On 8 December 2017 at 20:12, Jiri Svoboda <[email protected]> wrote:
> 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?
>
It's not really about liking/disliking errno_t. The problem is with
overloading
a small set of preexisting error conditions with widely inconsistent
meanings.
If you use <errno.h> constants everywhere, you have two choices. Either
you add to the system-wide header every time you need to represent a new
error condition (i.e. the POSIX way), or you arbitrarily assign new meanings
to the old constants. The former only works for code that's an inherent part
of the OS, which is fine when running a monolithic system, but in a system
like ours, restricting all errors to a centrally curated set seems
counter to the
spirit of the multi-server environment.
Currently, HelenOS code base does a mix of the two approaches.
> 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.
>
If you haven't put care into the ways the API can fail, you should probably
just return -1 on every failure. It has the same expressive power, and it's
less
prone to mistakes due to wrongly assuming certain semantics for certain
error codes.
My main concern is in how easy/difficult a given error-handling scheme is
to use incorrectly. Simply passing arbitrary numbers via typeless channels
is just about the most error-prone way possible (no pun intended).
> 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 :-)
>
Agreeing on common guidelines would be very nice. :)
>
>
> ---------- 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
>
_______________________________________________
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
