Re: [Qemu-devel] [PATCH 00/10]: QError v4

[Anthony Liguori <anthony@codemonkey.ws>]

Luiz Capitulino wrote:
> On Fri, 20 Nov 2009 09:56:46 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>> Jamie Lokier wrote:
>>     
>>> Anthony Liguori wrote:
>>>   
>>>       
>>>> Markus Armbruster wrote:
>>>>     
>>>>         
>>>>> 3. It falls short of the requirement that clients can easily present a
>>>>>   human-readable error description to their human users, regardless of
>>>>>   whether they know the error or not.
>>>>>  
>>>>>       
>>>>>           
>>>> That's just incorrect.  We provide an example conversion table that's 
>>>> akin to strerror() or a __repr__ for an exception in Python.
>>>>     
>>>>         
>>> Markus refers to errors that the client does not know - i.e. when the
>>> client is older than qemu, or is not in the same development branch if
>>> it's a branched qemu.  Which means the client won't have a fully up to
>>> date conversion table.
>>>       
>
>  What's the proper fix for this? I can only think of having QError on
> library, which is what we're going to do, anyway.
>   

There are two use cases to consider.  The first is logging of errors.  
Logging the json representation of a QError should be just as good for 
postmortem debugging as a formatted description.  That's really the 
point, there is no additional information in the formatted description.

The second use case is presenting an error message to a user.  My 
contention is that a good UI is not going to present an unknown error to 
a user either in JSON representation or in a non-localized string.  Both 
are equally gibberish to non-English speakers.

I think your suggestion of just offering the error class is the best 
I've heard so far.  That at least makes the message google-able.

>>> Do you mean qemu provides it's current conversion table to the client
>>> over the wire protocol?
>>>   
>>>       
>> (qemu) format_error "{'class': 'DeviceNotFound', 'data' : {'addr': 
>> '00:11:22'} }"
>> Device 0:11:22 is not present
>>
>> Is what I'm thinking.  I don't think it's needed but it solves the 
>> "problem".
>>     
>
>  Couldn't the client print the error class for errors it doesn't
> know about? Like:
>
> "Unknown error: 'CloudProtocol'"
>
>  I know this is bad, but seems a lot better than printing something
> with the wrong locale (ie, 'desc').
>   

Yes, I agree completely.  I was offering format_error only as a 
concession.  I honestly believe that the structured data is just as good 
to a developer as the message and that the message if not localized is 
gibberish to the user.

Regards,

Anthony Liguori