On Thu, Sep 6, 2012 at 7:00 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Thu, 6 Sep 2012 13:18:15 +0900 Daniel Juyung Seo <seojuyu...@gmail.com> > said: > >> On Thu, Sep 6, 2012 at 8:54 AM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > On Thu, 6 Sep 2012 01:14:34 +0900 Daniel Juyung Seo <seojuyu...@gmail.com> >> > said: >> > >> >> I am sick and tired of hearing that "EFL code sucks" because of those >> >> missing exception handlings. >> > >> > and do these people bitch about libc too? checking the programmers bad and >> > non-sensical input is a nicety we do in some places. it is a NICETY! not a >> > requirement. libc sees it as a luxury and almost never does it. my bet is >> > they don't complain about libc. they simply want to pass blame away from >> > their own mistake and thus will say "well efl sucks". >> >> libc is so low level. That's the difference between libc and efl. >> >> > >> > if we do any checking it should be consistent throughout a library. e_dbus >> > doesn't check most input as it's a thin wrapper. any checks should use >> > standard/common infrastructure where appropriate so it can be a macro and >> > compiled out for speed reasons or change behavior (eg call abort() on every >> > incorrect input to guarantee you get a crash and a backtrace to fix it). a >> > simple 'if (!string) return NULL;' is more likely to hide nasty bugs and >> > make them much harder to find. there is no complaint to stout/err. there is >> > no way to force a backtrace (abort) etc. >> >> This is exactly what I agree. Be consistent. >> So what's your opinion? Check NULL in EFL or not? > > at this moment "follow the pattern FOR THAT LIB". that means eet is different > to ecore, different to evas etc. > > as such in the more general sense, abort() or just not checking OBVIOUS params > (like char *name if the function couldn't work sensibly without a string name) > is acceptable. if its going to be done it must be done with a macro that can > enable/disable the checks and suitably complain to stdout/err (eina_log), and > probably abort() too given certain build or runtime setups (env vars). thats > the GENERAL case. specifically be consistent within a single lib. FIRST. so > fix > up missing checks in a lib that mostly does checks FIRST. ignore libs that > don't do it until the others are fixed. if u add them to one that doesn't then > do it all over as per the above - macros, on/off, log, abort etc. > > though the lowest level (eina) i think can live without in most cases as it's > at the same level as libc in terms of being "low level".
Yes your explanation makes perfect sense. But we are going to merge core efl libraries in a single tree this year. So... Daniel Juyung Seo (SeoZ) > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
