qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 00/10]: QError v4
Date: Fri, 20 Nov 2009 10:27:27 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Luiz Capitulino wrote:
On Fri, 20 Nov 2009 09:56:46 -0600
Anthony Liguori <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]