From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfZwF-0006j1-9F for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:04:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfZwC-0000GQ-NA for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:03:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfZwC-0000Fy-F9 for qemu-devel@nongnu.org; Fri, 15 Jun 2012 13:03:56 -0400 Date: Fri, 15 Jun 2012 18:03:50 +0100 From: "Daniel P. Berrange" Message-ID: <20120615170350.GO16777@redhat.com> References: <1338387301-10074-1-git-send-email-lcapitulino@redhat.com> <1338387301-10074-3-git-send-email-lcapitulino@redhat.com> <4FC74B1A.8080700@redhat.com> <20120531110608.4dc3fe22@doriath.home> <4FC77F6C.8000008@redhat.com> <20120531113127.1c8aa213@doriath.home> <4FC78637.4040605@redhat.com> <20120613144910.598bfe24@doriath.home> <4FDB6869.1000509@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4FDB6869.1000509@us.ibm.com> Subject: Re: [Qemu-devel] Adding errno to QMP errors Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, armbru@redhat.com, Luiz Capitulino On Fri, Jun 15, 2012 at 11:52:57AM -0500, Anthony Liguori wrote: > On 06/13/2012 12:49 PM, Luiz Capitulino wrote: > No, you're confusing things I think. { 'error': 'NoSpace' } is bad. > errno is not an intrinsically bad thing but errno critically relies > on the *caller* to understand the context that the error has > occurred in. Just returning { 'error': 'NoSpace' } is not good > enough in QMP because the caller doesn't know the context. What was > the command doing such that that error was returning? > > In many cases, errno has different meanings depending on the > context. EINVAL is a good example of this. > > The devil is in the details here. Having an error like: > > { 'error': 'OpenFileFailed', 'file': 'filename', 'mode': 'r/w', > 'os_error': 'enospc' } > > is actually pretty reasonable for something like a memory dump > command where the user specifies a file. I can't help thinking that we're still over-engineering the error reporting for QMP, and that really all we need is a reasonably coarse error code/class, and an informal string. eg, { 'error': "SystemError", msg = "failed to open file '/foo/bar' for writing: no space on device" } { 'error': "DNSError", msg = "unable to resolve hostname 'foo': cannot reach nameserver"} etc In libvirt we started with a ridiculously complicated virErrorPtr struct, which no one ever remembered to fill our details in, or filledout details inconsistently. These days we only ever bother with a coarse error class, and a string, and in the case of a system error, we also include the raw errno value. Pretty much all common APIs / languages focus primarily on just an error code/class and a informal string too, with the odd exception eg Python's OSException provides you the errno value too Are any users of QMP actually asking for this kind of advanced error reporting ? From libvirt's POV we're perfectly content with just an error class & string. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|