[Qemu-devel] Re: [RFC 0/7] QError v1

[Luiz Capitulino]

On Fri, 30 Oct 2009 08:59:43 -0500
Anthony Liguori <address@hidden> wrote:

> Luiz Capitulino wrote:
> >  Seems ok to me, but to make it harder to reuse existing error
> > codes we'd have to:
> >
> > 1. Make mandatory the use of a macro in the qemu_error_structed()
> >    call
> > 2. All macros would have to be defined in qerror.h
> >   
> 
> Not really.  All you need is to switch code to something that's more 
> easily definable like a string.  So...
> 
> #define QERR_DEV_NFOUND "{ 'code': 'DevNotFound', 'name': %s}"
> 
> Now you can define this anywhere.

 In this approach error codes can be freely defined/created by
commands, right? No problem in having generic errors in qerror.h,
do you agree?

 This specific example is generic, IMO.

 Flexible, and easier to use. I'm just wondering if it's a good idea
to have them "spread" over QEMU, as opposite to having then centralized
in qerror.h.

> >  Btw, why are you calling it qemu_error_structured()? It's a long
> > name, let's call it qemu_erro_structed() or any better name.. I
> > thought about qemu_error_throw()..
> >   
> 
> How about qemu_error_new().  It returns a QObject and I assume we'll 
> just return an error object instead of returning a normal result, correct?

 Yes, but it doesn't return the error object as a return value.

 If we're in the monitor, the error object is stored in the Monitor
struct, which will be later checked when the handler returns. If we
were called from the command-line, the error object is printed right away.

 That's way I think qemu_error_throw() makes more sense.

> >> I agree that a bit more generic error messages wouldn't be a bad thing.
> >>     
> >
> >  I think we're back to the discussion regarding what information
> > an error should contain.
> >
> >  Daniel seems to want as most info as possible:
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg01640.html
> >
> >  In case we put only the error code and error data on the wire,
> > I think error codes should be *unique* and not generic. This way
> > clients are able to determine the exact error cause.
> >
> >  If we go with generic errors, then we would have to send the
> > user string along. This introduces the problem of localization
> > and can be a bit redundant, as the call above would be emitted
> > like:
> >
> > { "error": { "code": 404,
> >              "desc": "driver foobar not found",
> >              "data": { "name": foobar" } } }
> >   
> 
> I think this is a problem that we don't have to solve yet.  Let's get 
> the error format down first and then we can consider how granular the 
> errors ought to be.

 I'm trying to avoid making decisions now, and discovering too late
they weren't good enough.