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

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Wed, Aug 09, 2006 at 12:52:54PM -0400, Daniel Veillard wrote:
> 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:
> > > 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.

In particular it makes debugging significantly harder. If you get an error
message a and want to correlate it back to the piece of code which triggered
it, you will only be able to correlate a stack trace back to a particular set
of calls. To correlate further back to a specific call will require re-running
the program and single stepping in a debugger. For example if you got say
a 'permissions denied' error from a particular location in the code, you've
no way of determining which of the preceeding 4-5 API calls it was caused
by. The 'clutter' of checking & dealing with errors at the location they
occurr is well worth it, being offset by greater clarity when later debugging
the code. This approach to error handling is best exemplified by the standard
C library, or POSIX system call APIs - checking each & every call you make 
may require more code, but it is absolutely key to creating predictable,
reliable & clear to debug programs.

Having each method provide an explicit return status complies with the 
'principle of least surprise' - if one sees a method which returns void,
the expected semantics are that is does not have failure conditions.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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