qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 6/9] QError: Add qdev not found error


From: Hollis Blanchard
Subject: Re: [Qemu-devel] [PATCH 6/9] QError: Add qdev not found error
Date: Thu, 15 Oct 2009 15:44:47 -0700

On Thu, 2009-10-15 at 16:27 -0500, Anthony Liguori wrote:
> address@hidden wrote:
> > It's hard enough to keep localized strings updated for every release
> > within a single code tree. Beyond that, you expect that every *client*
> > will update its localized strings for every *server* release?
> 
> What I meant by highly structured is that you wouldn't pass a string at 
> all.  There would just be an error code and whatever information went 
> along with that error code.  It would be up to the client to decide how 
> to present a message to the user.
> 
>  From a usability perspective, this is better both for localization but 
> also to ensure a consistent user experience with respect to how errors 
> are described to a user.
> 
> Basically, I think the conventional wisdom in UI design is that you 
> never want to pass error messages from a  server directly to a user.

I think it's also conventional wisdom not to show the user vague "some
error occurred" messages. :)

How about this (basically what Paolo suggested):

{ "error": { "code": 12,
             "desc": "device %{bus}:%{address} already open",
             "data": { "bus": 0, "address": 12 } } }

'desc' *may* be used by the client, or may be replaced with a localized
version. This ensures that users need never be confronted with an
"Error: 12" dialog box; a client can at least display some (English)
information for unknown errors.

I am now seeing how Luiz got to where he did with the original patch:
once you have unique error codes, why embed the format string at the
call site? (I think this would have been a better patch description in
the first place, rather than unspecified "compatibility".)

However, I think the part that's still bothering me is the user_print
function pointer. It seems to me that there should be no difference
between the text sent to a remote client and the text displayed to a
local user, and if that were true it would remove some ugliness.

-- 
Hollis Blanchard
IBM Linux Technology Center





reply via email to

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