[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object
Date: Mon, 07 Mar 2011 08:24:13 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

On 03/07/2011 05:06 AM, Daniel P. Berrange wrote:
On Sun, Mar 06, 2011 at 07:22:45PM -0600, Anthony Liguori wrote:
The Error class is similar to QError (now deprecated) except that it supports
propagation.  This allows for higher quality error handling.  It's losely
modeled after glib style GErrors.
I know this offers more functionality than GError, but if we're going
to be using GLib IMHO it would be very desirable to just use GError
everywhere. Are the extra arbitary key,value pair fields really a
compelling enough addition to make us not use GError ?

So here's the rational for not using GError (or really any message based Error object).

GError uses a domain, code, and message. Since theses errors escape over the wire, the message part ends up not being very useful for clients.

There's no way to exhaustively enumerate all of the possible messages from the client's perspective which means there's no way to provide a localized version of the message. That means that if a management tool wishes to expose these messages, they'd have to expose the English string which is extremely undesirable.

With the current Error design, a management tool can create a localized error message table to use to generate proper messages for end users. It can also make designs based on additional error content.

Using GError would basically devolve into having an error code. It's doable, but if we were going to use an error code, I wouldn't want to have a custom message parameter and instead use a generated string. My concern is that people will put critical information in the message parameter that a management tool is unable to use. Worse yet, a management tool may end up parsing these strings and then we're stuck maintaining yet another format.

Just imagine the head ache of needed to worry about a formatted string that contains a file name and the file name contains special characters... It's the monitor all over again.


Anthony Liguori

libvirt started
off with a very flexible error object that allowed extra string&  int
values to be passed with each error, but after 5 years dev there is
not a single place in our code where we use this. Simple error code
and formatted strings have been sufficient, much like GError would


reply via email to

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