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
|
Home