From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3s1N-000572-VZ for qemu-devel@nongnu.org; Fri, 30 Oct 2009 10:00:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3s1H-00055R-2C for qemu-devel@nongnu.org; Fri, 30 Oct 2009 10:00:03 -0400 Received: from [199.232.76.173] (port=59822 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3s1G-00055B-7w for qemu-devel@nongnu.org; Fri, 30 Oct 2009 09:59:58 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:33525) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N3s1F-0007Hs-QE for qemu-devel@nongnu.org; Fri, 30 Oct 2009 09:59:58 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9UE5DK2029148 for ; Fri, 30 Oct 2009 10:05:13 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9UDxpf8083262 for ; Fri, 30 Oct 2009 09:59:54 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9U7wCxm024219 for ; Fri, 30 Oct 2009 01:58:12 -0600 Message-ID: <4AEAF14F.40407@us.ibm.com> Date: Fri, 30 Oct 2009 08:59:43 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1256841750-15228-1-git-send-email-lcapitulino@redhat.com> <4AEA133A.8010906@redhat.com> <20091030102809.1c520282@doriath> <4AEAE261.5030908@redhat.com> <4AEAE56E.8040309@us.ibm.com> <20091030114716.02d7ac3e@doriath> In-Reply-To: <20091030114716.02d7ac3e@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC 0/7] QError v1 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Paolo Bonzini , hollisb@linux.vnet.ibm.com, Gerd Hoffmann , qemu-devel@nongnu.org Luiz Capitulino wrote: > Seems ok to me, but to make it harder to reuse existing error > codes we'd have to: > > 1. Make mandatory the use of a macro in the qemu_error_structed() > call > 2. All macros would have to be defined in qerror.h > Not really. All you need is to switch code to something that's more easily definable like a string. So... #define QERR_DEV_NFOUND "{ 'code': 'DevNotFound', 'name': %s}" Now you can define this anywhere. > Btw, why are you calling it qemu_error_structured()? It's a long > name, let's call it qemu_erro_structed() or any better name.. I > thought about qemu_error_throw().. > How about qemu_error_new(). It returns a QObject and I assume we'll just return an error object instead of returning a normal result, correct? >> I agree that a bit more generic error messages wouldn't be a bad thing. >> > > I think we're back to the discussion regarding what information > an error should contain. > > Daniel seems to want as most info as possible: > > http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg01640.html > > In case we put only the error code and error data on the wire, > I think error codes should be *unique* and not generic. This way > clients are able to determine the exact error cause. > > If we go with generic errors, then we would have to send the > user string along. This introduces the problem of localization > and can be a bit redundant, as the call above would be emitted > like: > > { "error": { "code": 404, > "desc": "driver foobar not found", > "data": { "name": foobar" } } } > I think this is a problem that we don't have to solve yet. Let's get the error format down first and then we can consider how granular the errors ought to be. Changing the types of errors thrown is easy to do without breaking compatibility. -- Regards, Anthony Liguori