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

[Gareth S Bestor <bestorga@xxxxxxxxxx>]

>Therefore, rather than
>
>uint64_t result = xen_vm_get_thingy(session, param1, ..., paramn);
>if (!session->ok) {
>  // error handling
>}
>
>how about we have instead
>
>uint64_t result;
>if (!xen_vm_get_thingy(session, &result, param1, ..., paramn))
>{
>  // error handling
>}
>
>Personally, my choice would be for the first, but if the weight of the world
>is against me, I can yield ;-)

Without stepping into a 'religious' minefield here... :-) ignoring the various pros and cons of
both approaches - which I'm not qualified to express an opinion about - I think the reality is that
the first error handling approach probably wont fly in the broader Xen devel community - its a bit too atypical C.
So unless there is a significant and obvious advantage to it (and I sense its more personal preference
between here), I think the latter style that gets away from the session will get more buyin from developers
and so get them onboard with the new API sooner; one less thing for them to compain about. :-)

- G

Ewan Mellor <ewan@xxxxxxxxxxxxx>

Ewan Mellor <ewan@xxxxxxxxxxxxx>
Sent by: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

08/10/06 03:55 AM

To	John Levon <john.levon@xxxxxxx>
cc	Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Subject	Re: [Xen-API] Xen-API C Bindings, version 0.4.1

On Thu, Aug 10, 2006 at 12:51:57AM +0100, John Levon wrote:

> On Wed, Aug 09, 2006 at 05:26:34PM +0100, Ewan Mellor wrote:
> 
> > >   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).
> 
> I don't think the issue is whether it's possible to do so, but whether it's
> natural. It's rather unnatural IMO to have this out-of-band error notification
> in a C API. It's hard enough to get people to check return values when they
> exist, never mind when they're implicit. (Yes, people should always strive to
> get this right, but the perfect never happens, so it's really all about
> minimising the error as much as possible...)

OK, how's this:

I think that it's important to treat all return values the same, because I
want someone to be able to look at the Xen API document, the
language-independent one, and for them to be able to infer how the C API
should look.  Further, I worry about the case where a value doesn't have a
reasonable sentinel, such as an integer that can reasonably take any value in
the range.

Therefore, rather than

uint64_t result = xen_vm_get_thingy(session, param1, ..., paramn);
if (!session->ok) {
  // error handling
}

how about we have instead

uint64_t result;
if (!xen_vm_get_thingy(session, &result, param1, ..., paramn))
{
  // error handling
}

Personally, my choice would be for the first, but if the weight of the world
is against me, I can yield ;-)

This second form is no more complicated, so I can change the bindings over.
In particular, this means that there will be no remote call that returns void,
which is the thing that the Daniels didn't like.  Calls to the server that
return no result look like this instead:

if (!xen_vm_do_something(session, param1, ..., paramn))
{
  // Call failed
}

How's that for an alternative?

Ewan.

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

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