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

[Daniel Veillard <veillard@xxxxxxxxxx>]

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. 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.
  I completely agree with Dan that the API should encourage proper 
error handling by making test easy and following common convention which
is to return error code which can be easilly tested. Then also having
a more complete way to extract errors should be provided (including
more complete error code and optional context informations) and those 
should use the context, yes.
 IMHO doing error checking on each operation which can fail is not
cluttering code, it is writing good code. Writing the code in the first
place is a small effort in comparison of debugging and maintaining it,
optimizing for the first, cheapest operation at the expense of the others
is, I think, a bad decision.

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