Re: [E-devel] EFL error handling (was: checking a part's type?)

2008-04-20 Thread Gustavo Sverzut Barbieri
On Fri, Apr 18, 2008 at 11:01 AM, Michael 'Mickey' Lauer
[EMAIL PROTECTED] wrote:
   We could put checks like this in edje_object_part_swallow. But I can't
help to
think was programmed to work this way for a reason I ignore.
  
   All ELFs are written in this way, without error checking and reporting, i
   think it's for performance reason and I like it :)

  I sincerely hope that this was an ironic statement. The complete lack of 
 error
  handling in the EFL (well, apart from image loading) is dooming like the
  sword of damocles. I'm afraid as EFL gets more popular this will be a _major_
  hindrance for professional adoption and I'd really like us to revisit this
  before it's too late (read: stable APIs).

I very much agree with Mickey, as I said before. While I do like the
library not breaking for minor purposes, I think that most silent
ignore of errors is bad. I'd like to see most of the calls to return
at least a boolean with Yes/No.

However I _REALLY DOUBT_ someone from core will have the time to go
through the API and change methods to use that, so we could find out a
newbie that wants to contribute, this is a good way to get started!
Someone would like to try? This also holds for bindings, at least
proto/python-efl would need to be adapted to check for such errors.

PS: Evas and some other parts have magic checks on library entry
points, they can be configured by setting MAGIC_DEBUG (on by default)
and then using env-vars EVAS_DEBUG_SHOW and EVAS_DEBUG_ABORT. So this
kind of check _IS_ already done in some parts of the code, is not
about blindly going and replace all functions to return Evas_Bool.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] EFL error handling (was: checking a part's type?)

2008-04-18 Thread Michael 'Mickey' Lauer
  We could put checks like this in edje_object_part_swallow. But I can't
  help to
  think was programmed to work this way for a reason I ignore.

 All ELFs are written in this way, without error checking and reporting, i
 think it's for performance reason and I like it :)

I sincerely hope that this was an ironic statement. The complete lack of error 
handling in the EFL (well, apart from image loading) is dooming like the 
sword of damocles. I'm afraid as EFL gets more popular this will be a _major_ 
hindrance for professional adoption and I'd really like us to revisit this 
before it's too late (read: stable APIs).

:M:
-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel