[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] Xen-API C Bindings, version 0.4.1



On Wed, Aug 09, 2006 at 05:26:34PM +0100, Ewan Mellor wrote:
> On Wed, Aug 09, 2006 at 12:12:59PM -0400, Daniel Veillard wrote:
> 
> > On Wed, Aug 09, 2006 at 04:04:40PM +0100, Ewan Mellor wrote:
> > > It's not that odd -- it's an approach I've seen used in a number of 
> > > libraries
> > > before -- xmlrpc-c most recently, but also with CORBA bindings that I've 
> > > used
> > > in the past.  This approach has two advantages: you can chain calls 
> > > together
> > > without having to clutter the code with error checking, and when you 
> > > return a
> > > value, you don't need to decide which value is to be your error code.
> > 
> >   Sorry, that's horrible, because you loose locality of the error.
> > Errors should be detected as soon as possible to be able to report 
> > them as accurately as possible.
> 
> If you want to detect them as soon as possible, just have if (session->ok)
> after every call.  It's no harder than if (return_value == NULL/-1/0/false).

  Well I think it's a big difference. In C a void call will always be
interpreted as a no side effect one. And as Dan pointed out with a mini
example the code really ain't the same. If would not inflict that coding style
on a python person, but that's the normal one for C. You ask for feedback
on C binding, well I tell you, sorry if we disagree.

> Errors should be reported well, because you've got the additional benefit of 
> parameterised, internationalisable error messages.
> 
> > Point in case I have a domain which
> > doesn't start, failure occurs within xend in XendDomainInfo::initDomain
> > you got a big try:/except: where most of the hard and prone to fail code
> > sit and basically errors are handled only at the end. Result: you just
> > get 
> > 
> >     in initDomain
> >         raise VmError(str(exn))
> >     VmError: (9, 'Bad file descriptor')
> > 
> > as the informations to work with. Sorry encouraging this kind of error
> > handling is a mistake, not an advantage.
> 
> That's unfair.  Firstly the error comes from the C binding, and is bounced
> across into Python through an interface layer.  It's the fact that we only
> have errno available across that interface that the error reporting is so
> poor.  Secondly, the fact that you always get "Bad file descriptor" rather
> than a more useful error code is a bug, one that was fixed by your colleague
> Steven Rostedt yesterday.

  Okay, but I'm not arguing about this precise case but about the coding
practice in general, if I had a C example that would have been better, I
agree, Python practice is different. Still the 'check and catch fire only
at the end' makes things harder in my opinion.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.