Anthony Liguori <anth...@codemonkey.ws> writes:
> Luiz Capitulino wrote:
>> On Fri, 20 Nov 2009 09:56:46 -0600
>> Anthony Liguori <anth...@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.
Incomplete localization should fail gracefully. That's why gettext()
returns its argument when the message catalog doesn't have a
translation.
This might be gibberish for some users, but even then it's eminently
google-able gibberish.
Moreover, not all users preferring a non-English locale are unable to
figure out an English message, either by themselves or with help from a
friend.
I figure the set of human users who can handle JSON better than English
is vanishingly small.
> 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.
A properly localized description of the error class can't replace the
full error message, because it is less specific. But it's a fine
supplement. Of course, you may lack a translation for the error class,
as well. Should be less likely, though, because error classes should
change less frequently than instances.
>>>> 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.
Good tools make the simple simple and the difficult possible.
Besides sophisticated management tools solving difficult problems, we
should make QMP as easy and convenient as possible for simple tools,
like ad hoc scripts. If such scripts have to jump through hoops to get
error reporting fit for human beings, we failed the "make the simple
simple" part.
