From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mzu9V-0006BU-0p
	for qemu-devel@nongnu.org; Mon, 19 Oct 2009 11:28:05 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mzu9O-0006A5-UV
	for qemu-devel@nongnu.org; Mon, 19 Oct 2009 11:28:03 -0400
Received: from [199.232.76.173] (port=58865 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mzu9O-00069v-LX
	for qemu-devel@nongnu.org; Mon, 19 Oct 2009 11:27:58 -0400
Received: from fg-out-1718.google.com ([72.14.220.153]:24058)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1Mzu9O-0006O6-A9
	for qemu-devel@nongnu.org; Mon, 19 Oct 2009 11:27:58 -0400
Received: by fg-out-1718.google.com with SMTP id d23so1932917fga.10
	for <qemu-devel@nongnu.org>; Mon, 19 Oct 2009 08:27:57 -0700 (PDT)
Message-ID: <4ADC8577.1030107@codemonkey.ws>
Date: Mon, 19 Oct 2009 10:27:51 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 7/9] qdev: Use QError for not found error
References: <1255453026-18637-1-git-send-email-lcapitulino@redhat.com>	<1255453026-18637-8-git-send-email-lcapitulino@redhat.com>	<877huy6hzm.fsf@pike.pond.sub.org>	<20091019101241.GA27871@redhat.com>
	<4ADC7101.6020002@us.ibm.com> <20091019152159.GN27871@redhat.com>
In-Reply-To: <20091019152159.GN27871@redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, Luiz Capitulino <lcapitulino@redhat.com>, qemu-devel@nongnu.org, kraxel@redhat.com

Daniel P. Berrange wrote:
> Having a named "exception" instead of an error code is fine, but I think
> it is overkill to include fully-structured data fields like 'errno' instead
> of just a string. The libvirt application API has a insanely detailed 
> error object allowing for passing of structured data back to apps, but 
> I'm not aware of any application that has ever used it.  They all just
> hook on the error code, and log/print detailed string message field. 
>   

Just because the current consumers are lazy doesn't mean we should 
restrict the API.

> In terms of libvirt using QMP error data, there may be one or two
> places where we'd toggle behaviour off an error code / exception type,
> but any futher structured data would likely just be converted to a generic
> string message. So I don't see much need for anything beyond a error code
> or exception type to be used for behaviour decisions, and a detailed string
> description for logging.
>   

While it gets complicated when going through things like libvirt, if we 
design the python bindings for libqmp directly, these will appear as 
proper exception objects with members corresponding to the data. I would 
fully expect that users would use the structured exception data in a 
language like Python. For instance, when changing a cdrom iso, being 
able to handle EPERM and ENOENT separately is very valuable.

Regards,

Anthony Liguori