On Thu, 11 Aug 2016 16:15:37 -0300 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> 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 a single global (per thread) error type? no enums. no type checking. what? how on earth can you like this? errno is a horrible error design. not to mention reading and writing these means a tls access and tls accesses are NOT CHEAP. they are not just another register/var on stack. it turned out tls accessed were one of the major bit of eo overhead that we've removed. > 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. but then all you have is an int as an error. a single GLOBAL error enum space for ALL errors. eh? this is a nasty way of doing errors that is hard to extend. forget exceptions, js etc. - in C it's bad. return errors. if its as simple as a boolean even better as its easier to work with, otherwise come up with something sensible for that api. but aside from all of that ... ALL Of EFL uses returns for errors. look through efl for eina_error_set - the C code... seriously. it's basically never used. efl_io_manager.c, and edje_edit.c in a few places , some in eina_promise.c (and eina_safety_checks.c) - and 1 in elm_photocam.c we DONT USE eina error. it's not the design pattern nor the style. don't start using it here because it just doesn't follow the design pattern for efl. in fact efl_io_manager.c only sets eina_error to 0 - pointless as it's not being set to anything else. same for edje_edit.c - i should remove those as they are actually pointless pieces of code that give the wrong impression - that we use eina_error. so the ONLy place it is actually used to indicate an error that is not pointless (0 for no error or dead or soon to be dead code) is: elm photocam.c eina_safety_checks.c 2 instances of it in all of efl. > 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. we don't use eina error at all effectively. returning an error enum is how we do things if we have an error that is non-boolean (ie its fail then u get null/false or it succeeds and u get true or a valid ptr etc.). with some places allowing for enum values to get. > 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. not if we are to be consistent in usage. our usage patterns do not involve eina_error. > >> [snip] > >> > >> Regards, > >> -- > >> Felipe Magno de Almeida > > Regards, > -- > Felipe Magno de Almeida > -- ------------- 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
