From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Myncx-0001t4-Dz
	for qemu-devel@nongnu.org; Fri, 16 Oct 2009 10:17:55 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mynct-0001qT-Qy
	for qemu-devel@nongnu.org; Fri, 16 Oct 2009 10:17:55 -0400
Received: from [199.232.76.173] (port=36435 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Myncr-0001q5-2v
	for qemu-devel@nongnu.org; Fri, 16 Oct 2009 10:17:49 -0400
Received: from mx1.redhat.com ([209.132.183.28]:55131)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <lcapitulino@redhat.com>) id 1Myncq-0004ug-JT
	for qemu-devel@nongnu.org; Fri, 16 Oct 2009 10:17:48 -0400
Date: Fri, 16 Oct 2009 11:17:27 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 6/9] QError: Add qdev not found error
Message-ID: <20091016111727.3e63112c@doriath>
In-Reply-To: <4AD87735.2030509@us.ibm.com>
References: <1255453026-18637-1-git-send-email-lcapitulino@redhat.com>
	<1255453026-18637-7-git-send-email-lcapitulino@redhat.com>
	<1255561330.29192.2.camel@slab.beaverton.ibm.com>
	<20091015103405.591e2f3b@doriath>
	<1255626960.29192.7.camel@slab.beaverton.ibm.com>
	<20091015145208.1d871f09@doriath>
	<1255630433.29192.16.camel@slab.beaverton.ibm.com>
	<20091015160839.7dbef5bf@doriath> <4AD8211B.9090004@redhat.com>
	<4AD87735.2030509@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
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: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>, hollisb@linux.vnet.ibm.com

On Fri, 16 Oct 2009 08:37:57 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> Gerd Hoffmann wrote:
> >   Hi,
> >
> >> { "error": { "code": 404,
> >>               "desc": "husb: host usb device 0.12 is already open" } }
> >>
> >>   In case I'm right, there are two problems with it:
> >>
> >> 1. It's hard to retrieve the variable information
> >
> > Markus asked it already, I'm asking again:
> >
> > *Do we actually need the variable information?*
> >
> > The point is that the information usually is available from context 
> > anyway, i.e. if you get the reply above from a command like 'usb_add 
> > host:0.12' you know it is host device 0.12 *without* parsing reply 
> > because you know you've asked for host device 0.12.
> 
> I would recommend treating errors like exceptions.  In fact, if I were 
> writing a python client library, this is exactly how I would model it.
> 
> In fact, it would make sense to switch code to some sort of class name.  
> This would be the exception class.  The data argument would be the 
> exception object.  desc would basically be __str__() method although 
> more limited.

 This seems useful (and a lot of C projects end up creating their
"error object" anyway), but I'm getting concerned.

 First, and more important, we have our immediate needs. Which is to have
most of the protocol code merged in 15 days.

 Second, I fear we are going too far with the objects idea. It
solves the monitor's problem well and although can be used by
other subsystems I wonder if pushing them to the extreme like that
is the way to go.