On 11/02/2010 06:05 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 02 Nov 2010 16:23:32 +0900 Mike McCormack<mj.mccorm...@samsung.com>
> said:
>
>>
>> btw. A nit of mine which I've mentioned before...
>>
>> Since you're going to check and "fail" it would be nice to return an
>> indication. That's a bit hard to do if everything returns void... any plans
>> to fix that?
>
> no. as that'd break api. :)
In general, adding int return where there was void does not break API, because
no code
could have relied on the undefined return. Function pointers are a special case
for which it will cause a source break, but there's still no ABI break.
The advantage of adding a zero return code now would be that you can extend APIs
that return error codes more easily. e.g. the case in evas where you currently
only
support a rectangular region but may support non-rectangular regions in the
future.
> there are environment vars that will cause aborts
> and prints/logging on errors for catching them, so return isnt needed as such
> as then every func needs the error catching done in the app - not in the lib.
> good luck getting everyone to check their errors. as such these kind of funcs
> should NEVER fail unless the user is literally mis-using them (bug in app -
> and
> if its an app bug how do u trust the app to also check all errors properly?)
> :)
> at least thats the topic here. recovering from potential segv/crash bugs at
> runtime by checking, allowing for even a buggy app to "survive longer" but it
> allows for catching the err if u set the env vars (and forcing a crash at that
> point).
Well, if you look at Daniel's suggestion, you can see there there's no way
to distinguish the "failed case" from the successful case, and the
failure is ignored.
EAPI void
elm_genlist_item_selected_set(Elm_Genlist_Item *it, Eina_Bool selected)
{
+ if (!it) return;
According to what you're saying, it should be:
EAPI void
elm_genlist_item_selected_set(Elm_Genlist_Item *it, Eina_Bool selected)
{
+ assert(it != NULL);
But that's kind of pointless, because you'll crash with a NULL pointer
dereference anyway.
thanks,
MIke
------------------------------------------------------------------------------
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware,
phishing sites, and compromised hosts - saving your company time,
money, and embarrassment. Learn More!
http://p.sf.net/sfu/hpdev2dev-nov
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
