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

[Anthony Liguori <aliguori@us.ibm.com>]

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.

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

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

Changing the types of errors thrown is easy to do without breaking 
compatibility.

-- 
Regards,

Anthony Liguori