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
