From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzuKk-00013G-LY for qemu-devel@nongnu.org; Mon, 19 Oct 2009 11:39:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzuKf-000124-05 for qemu-devel@nongnu.org; Mon, 19 Oct 2009 11:39:41 -0400 Received: from [199.232.76.173] (port=43326 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzuKc-00011k-MM for qemu-devel@nongnu.org; Mon, 19 Oct 2009 11:39:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12165) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MzuKc-000071-7I for qemu-devel@nongnu.org; Mon, 19 Oct 2009 11:39:34 -0400 Date: Mon, 19 Oct 2009 16:39:28 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 7/9] qdev: Use QError for not found error Message-ID: <20091019153928.GO27871@redhat.com> 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> <4ADC8577.1030107@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADC8577.1030107@codemonkey.ws> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Markus Armbruster , Anthony Liguori , Luiz Capitulino , qemu-devel@nongnu.org, kraxel@redhat.com On Mon, Oct 19, 2009 at 10:27:51AM -0500, Anthony Liguori wrote: > 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. That would suggest that the example exception type is wrong. Instead of naming the exception after the operation that failed, named it after the cause of the failure. ie, this {"error" : {"type": "OpenFailedException", "errno": errno}} would be better as one of... {"error" : {"type": "AccessDeniedException", "desc": "unable to open disk /tmp/demo.qcow"}}, {"error" : {"type": "NoSuchFileException", "desc": "file /tmp/demo.qcow does not exist" }} ....other specific causes of failure... {"error" : {"type": "SystemException", "desc": "file /tmp/demo.qcow does: ...some other strerror()..." }} which is more like the type of exception classification you get in Java, Python. Explicit named exception types for important problems, and then one generic 'SystemException' for less commonly encountered errno's. Of course Java/Python have inheritance, so AccessDeniedException and NoSuchFileException would be inherit from SystemException anyway. It is fairly rare to find exceptions providing more fine grained detail than just the string error message. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|