On Thu, 11 Aug 2016 17:48:13 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Thu, Aug 11, 2016 at 4:15 PM, Felipe Magno de Almeida > <felipe.m.alme...@gmail.com> wrote: > > On Thu, Aug 11, 2016 at 3:59 PM, Gustavo Sverzut Barbieri > > <barbi...@gmail.com> wrote: > >> Em quinta-feira, 11 de agosto de 2016, Felipe Magno de Almeida < > >> felipe.m.alme...@gmail.com> escreveu: > >> > >>> On Thu, Aug 11, 2016 at 11:23 AM, Gustavo Sverzut Barbieri > >>> <barbi...@gmail.com <javascript:;>> wrote: > > > > [snip] > > > >>> >>> is Eina_Error ok? > >>> >>> > >>> > will be kinda of a pain to map all possible errnos to enums, but i can > >>> > do it. (the other approach was to register all errnos at load time and > >>> > do a simple conversion as generic function eina_error_from_errno kinda > >>> > of thing). > >>> > >>> No. Please make it an Eina_Error! It is the only way to sensibly treat > >>> errors in bindings in a automatic-way. > >> > >> Ok :-) > >> > >> Please come to an agreement soon! > > > > @raster: We should use Eina_Errors for _everything_ in API. This allows > > C++ to treat errors as exceptions if the user doesn't care to check it > > itself (by using the overload with a std::error_code, which is, btw, already > > integrated to C++ with Eina_Errors), and also allows JS to throw > > exceptions, which is expected by users in these languages. I _may_ > > let it go with _some_(very few) functions that return bool (though I'd much > > prefer a more descriptive type, even if it is equal to a bool). But even > > then they should set a Eina_Error so users can really know what has gone > > wrong. > > > > If we start defining enums for each sub-library, because Eina_Errors > > are TLS, no application is going to check errors correctly. We should > > treat errors in consistent-way all over the API, so users are more > > likely to actually handle them. Our implementation, right now, doesn't > > set Eina_Error for most things, which is bad IMO. They just > > return a default value, usually, and the user (application developer) > > is left just wondering what is going on. > > > > Though I dislike TLS, which I _really_ _do_. IMO, if TLS is necessary > > for Eina_Error, then it is necessary. As we haven't yet fixed Eo ABI yet, > > we could think of something to avoid TLS in most cases, but that would > > likely really clutter the API. Still, Eina_Error is the way to go, even if > > it should return a Eina_Error to avoid TLS. > > Did you guys noticed I'm returning an error, not setting one to TLS, > right? It's a: > > return EINA_ERROR_OUT_OF_MEMORY; > > kind of thing, not: > > eina_error_set(EINA_ERROR_OUT_OF_MEMORY); > return; > > we can even @warn_unused_result to force people to handle that > properly and there should not be any issues with TLS. you you mean to return an Eina_Error - i thought you meant to set the eina_error global... returning that is probably fine. better than an int. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
