From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mzzan-0002ji-3P for qemu-devel@nongnu.org; Mon, 19 Oct 2009 17:16:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mzzai-0002hz-0z for qemu-devel@nongnu.org; Mon, 19 Oct 2009 17:16:36 -0400 Received: from [199.232.76.173] (port=33921 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzzah-0002hn-Mu for qemu-devel@nongnu.org; Mon, 19 Oct 2009 17:16:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60276) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mzzah-00050y-B7 for qemu-devel@nongnu.org; Mon, 19 Oct 2009 17:16:31 -0400 Message-ID: <4ADCD72B.2090302@redhat.com> Date: Mon, 19 Oct 2009 23:16:27 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <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> <1255637617.29192.59.camel@slab.beaverton.ibm.com> <4AD78CCD.6030006@us.ibm.com> <1255641511.29192.68.camel@slab.beaverton.ibm.com> <4AD793C6.9060508@us.ibm.com> <20091018042550.GH15656@shareable.org> <4ADB0775.8070404@redhat.com> <1255971040.13995.49.camel@slab.beaverton.ibm.com> In-Reply-To: <1255971040.13995.49.camel@slab.beaverton.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 6/9] QError: Add qdev not found error List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hollis Blanchard Cc: Anthony Liguori , Luiz Capitulino , kraxel@redhat.com, qemu-devel@nongnu.org On 10/19/2009 06:50 PM, Hollis Blanchard wrote: > On Sun, 2009-10-18 at 14:17 +0200, Paolo Bonzini wrote: >> On 10/18/2009 06:25 AM, Jamie Lokier wrote: >>> The manual for GNU gettext explains quite well why gettext takes a >>> message string as argument, instead of a "message code". Imho, a >>> similar case can be made for error messages at call sites. >> >> That's true. However here we have the case of having errors consumed by >> programs as well as users, so we want something that can be easily made >> into language bindings. >> >> In other words, this situation is much more similar to errno/strerror, >> than to a compiler error message (which will often be used by other >> programs, but where the actual error text will be read by a person; this >> can and should use gettext). > > So to extend your analogy, I think we're reaching the conclusion that > both errno *and* string should be returned to the client, right? I'd say so, yes. And any parameters too, all as JSON. I think errno is just one kind of data that can be in an exception, and you want different exceptions for not opening a sound device or not opening an image file (even if both may fail with EACCES or ENOENT). Paolo