From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43669 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwbMJ-0001DF-C5 for qemu-devel@nongnu.org; Mon, 07 Mar 2011 09:24:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PwbMI-0003h2-B4 for qemu-devel@nongnu.org; Mon, 07 Mar 2011 09:24:27 -0500 Received: from mail-gw0-f46.google.com ([74.125.83.46]:64188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PwbMI-0003gp-4k for qemu-devel@nongnu.org; Mon, 07 Mar 2011 09:24:26 -0500 Received: by gwj20 with SMTP id 20so2566932gwj.33 for ; Mon, 07 Mar 2011 06:24:25 -0800 (PST) Message-ID: <4D74EA8D.2010801@codemonkey.ws> Date: Mon, 07 Mar 2011 08:24:13 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 03/22] qapi: add Error object References: <1299460984-15849-1-git-send-email-aliguori@us.ibm.com> <1299460984-15849-4-git-send-email-aliguori@us.ibm.com> <20110307110600.GH21899@redhat.com> In-Reply-To: <20110307110600.GH21899@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, Adam Litke , Markus Armbruster , Luiz Capitulino 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 >