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

[Anthony Liguori]

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.

Regards,

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
> allow.
>
> Regards,
> Daniel
>