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
