Committed to master a change to allow using errno.h constants, check it out:
https://git.enlightenment.org/core/efl.git/commit/?id=e56811ed4db61ac2ac14d28a7a8fac83f41c43b8 On Tue, Aug 16, 2016 at 11:57 AM, Felipe Magno de Almeida <felipe.m.alme...@gmail.com> wrote: > On Tue, Aug 16, 2016 at 10:52 AM, Gustavo Sverzut Barbieri > <barbi...@gmail.com> wrote: >> On Tue, Aug 16, 2016 at 4:52 AM, Jean-Philippe André <j...@videolan.org> >> wrote: >>> Hi, > > [snip] > >>> But I'm not 100% sure about the usage of Eina_Error as a return value. When >>> we return a value, do we also call eina_error_set()? >> >> I was expecting to NOT eina_error_set(), since it's explicitly >> returned. But could set if you wish, do you? > > I'd rather not do that, otherwise another call could be seen as being > error'ed out > which hasn't, later on. Or the user would have to manually eina_error_set(0) > after, which means a TLS access (which is expensive as hell). > >>> In any case, Eina_Error at the moment can be used for exceptional cases and >>> APIs that don't or can't return precise error information (eg. return >>> NULL... but what failed?). Eg. a new patch I just pushed (set error to >>> timeout in timedwait). >> >> Eina_Error as in eina_error_set(), yes... it fixes the null-return in >> a "standard" way (given errno.h). >> >> Other options are: >> - never return pointers, just errors... kinda of PITA >> - encode errors on pointers... did that before, kinda of PITA as well > > IMO, most return NULL on error do not set eina_error because > nobody cared about Eina_Error. Most of these return NULL are > usually because of invalid arguments, and these are usually > checked through EINA macros which could just be changed to > do eina_error_set for a EINA_ERROR_INVALID_ARGUMENT > error. > > The problem between "return Eina_Error" vs "eina_error_set" is much > like C++'s problem of "return std::error_code" vs "throw exception". And > this is a problem very far from solved. The thing is: eina_error_set and > throwing exceptions are _very_expensive_, and can be dealt with in > a out-of-line error handling (not so much for eina_error_set, but at > least it doesn't require changes to function signatures). So, usually > the question when to use one or the other would be: Is the error > "common" or "an exceptional case"? > > For IO, I'd say errors are more common than exceptional (connection > errors, etc). However, that doesn't say much, because being rare > or not can only be defined by who uses it, and not by who defines > the function. That's why in C++ I'm going to add overloads for > std::error_code which will return a error_code, and the normal > overload will just throw an exception if an error has occurred, so > the user has complete freeedom to evaluate if errors are exceptional > or not. > > With eina_error_set, OTOH, since we don't have backtracking anyway > in C, the user is almost required to eina_error_get all the time to > check errors or detect returned NULL pointers. If he does'nt > care what the nature of the error is, then he can just return and leave > the eina_error_set as is for higher-level code to deal with the error > correctly. > > However, where no NULL pointers are involved, a eina_error_get > would be required, which is expensive. Which would mean more > verbose code and less-efficient code for no benefit. > > I'd say, if a function can fail, it either has some other way to check > for errors (like returning NULL pointers) or it should return an > Eina_Error. And all failures should eina_error_set if no Eina_Error > is returned, if it is returned then no eina_error_set should happen. > >> -- >> Gustavo Sverzut Barbieri >> -------------------------------------- >> Mobile: +55 (16) 99354-9890 > > Regards, > -- > Felipe Magno de Almeida > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
