From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sggk4-00025i-Ty for qemu-devel@nongnu.org; Mon, 18 Jun 2012 14:32:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sggk2-0001jh-W1 for qemu-devel@nongnu.org; Mon, 18 Jun 2012 14:32:00 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:56790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sggk2-0001jR-Mg for qemu-devel@nongnu.org; Mon, 18 Jun 2012 14:31:58 -0400 Received: by dadn2 with SMTP id n2so6710370dad.4 for ; Mon, 18 Jun 2012 11:31:56 -0700 (PDT) Message-ID: <4FDF7418.9070206@codemonkey.ws> Date: Mon, 18 Jun 2012 13:31:52 -0500 From: Anthony Liguori MIME-Version: 1.0 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> <20120615170350.GO16777@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Adding errno to QMP errors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, Luiz Capitulino , Paolo Bonzini On 06/18/2012 10:41 AM, Markus Armbruster wrote: > "Daniel P. Berrange" writes: > >> 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. > > Good match for real-world error handling, which is usually a minor > variation of > > if (didn't work) > if (retry might fix it) > retry > else if (I got a plan B to try) > try plan B > else > punt to human > > Error information used: > > 1. whether it failed > > 2. whether a failure is transient or permanent > > 3. a description of the failure fit for human consumption > >> 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. > > Real users, please, not theoretical ones. Irrespective of anything else, I think it's safe to say the experiment of "rich errors" has been a failure. We still have way too many places using error_report. As I mentioned in another thread, I think we should: 1) Introduce a GENERIC_ERROR QError type. It could have a 'domain' and a 'msg' field. 2) Focus on converting users of error_report over to use propagated Error objects. We shouldn't/can't change existing QError users. We also shouldn't consider changing the wire protocol. But for new error users, we should/can relax the reported errors. We need a clear support policy on whether the contents of 'msg' are stable or not too. Regards, Anthony Liguori