WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

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