From: Ian Campbell <ian.campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xen.org
Subject: Re: RFC: Proposal to improve error reporting in libxl
Date: Thu, 21 May 2015 17:49:01 +0100 [thread overview]
Message-ID: <1432226941.10746.111.camel@citrix.com> (raw)
In-Reply-To: <20150520090104.GE3119@citrix.com>
On Wed, 2015-05-20 at 10:01 +0100, Euan Harris wrote:
> We would like to make libxl's error reporting more regular and informative
> for callers.
Yes, I agree this is a good idea.
> We think we need to:
>
> * Make a list of the error conditions which can be encountered by
> all the current API calls and define a set of error codes to
> cover them. Some codes will be generally applicable, but give
> more information than a bare 'fail'; others may be specific to a
> particular API call. We may keep the existing FAIL, INVAL and
> NOMEM codes for times when they are appropriate.
>
> The error messages logged by each API call are a good starting point
> for this list. I have included a partial list below.
>
> * Change the API calls in point 1 above to use the new, more detailed
> error codes. These changes will break client code which checks for
> particular error codes, rather than just checking whether the return
> code is non-zero.
I think that at least for the case of turning a uselessly generic
ERROR_FAIL into something specific this is tolerable.
I'm not sure if we will want a raft of LIBXL_HAVE_ERROR_* defines. It
seems not all that useful.
(Perhaps every enum value FOO in the IDL should get a #define FOO FOO to
make this automatic?)
> * For the API calls in points 2 and 3 which can encounter errors
> which callers might care about, change their interfaces to return
> error codes. For functions which previously returned pointers,
> add pointer-to-pointer parameters.
I think this is doable using the LIBXL_API_VERSION arrangements
(described in libxl.h)
Essential for an existing
THING *get_a_thing_list(ctx, int *nr_r)
which you are converting to
int get_a_thing_list(ctx, THING **list_r, int *nr_r)
you would do something like:
#if LIBXL_API_VERSION < 0x406000 /* or whatever version */
static inline THING *get_a_thing_list(ctx, int *nr_r)
{
THING *list = NULL
int rc = get_a_thing_list(ctx, &list, nr_r);
if ( rc )
return NULL
else
return list;
}
#endif
Or something along those lines.
> * For error codes returned by utility functions, described in point 4,
> decide whether the code can be reported directly or an API-level
> error should be reported instead.
I think this fits in with the cleanups made in the second bullet and is
likewise fine. (But worth considering separately I agree)
Ian.
prev parent reply other threads:[~2015-05-21 16:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 9:01 RFC: Proposal to improve error reporting in libxl Euan Harris
2015-05-21 16:49 ` Ian Campbell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1432226941.10746.111.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=euan.harris@citrix.com \
--cc=ian.jackson@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.