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

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

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).
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.

Ewan.

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