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