From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NhpUh-0003qC-6m for qemu-devel@nongnu.org; Wed, 17 Feb 2010 14:23:31 -0500 Received: from [199.232.76.173] (port=53146 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NhpUf-0003p6-TV for qemu-devel@nongnu.org; Wed, 17 Feb 2010 14:23:29 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NhpUd-0007EU-Td for qemu-devel@nongnu.org; Wed, 17 Feb 2010 14:23:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41142) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NhpUd-0007EG-Dt for qemu-devel@nongnu.org; Wed, 17 Feb 2010 14:23:27 -0500 Date: Wed, 17 Feb 2010 17:23:17 -0200 From: Luiz Capitulino Message-ID: <20100217172317.266f18da@redhat.com> In-Reply-To: References: <4B75CA7B.7070906@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: QError conversion problems: putting errors in context List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Anthony Liguori , qemu-devel@nongnu.org On Mon, 15 Feb 2010 19:42:29 +0100 Markus Armbruster wrote: > Anthony Liguori writes: > > Thanks for the write-up. Here's my view of how error reporting ought > > to work: > > > > 0) A user tries to do something via some piece of code that serves as > > the UI. This may be the -device option handling, the config file > > parser, QMP, or the human monitor. > > 1) Something, somewhere, generates an error. This is may be as > > primitive as an errno or as sophisticated as a QError object. In both > > cases, the error consists of structured data will well defined > > semantics. > > 2) That error is propagated up the call chain back to the UI code. > > 3) The UI code then decides how to present the error to the user. > > This is how QError actually works. The trouble is that our error > presentation is too primitive. I wouldn't say this is how QError works today because UI can't decide how to present the error, this becomes an issue if the UI wants to add context information. Now, I agree that error presentation is too primitive and I think we will have to split this part out of QError in order to fix that. > > In an ideal world, qdev_device_add would either return a QError object > > or just an errno. The caller of qdev_device_add would then decide how > > to display that error to the user. > > > > The whole notion of having a description table baked into QError is > > wrong IMHO. You want as much contextual information as possible when > > generating an error for a user and the place you have that is at the > > point you're interacting with the user. It makes no sense to generate > > error messages deep in the bowels of QEMU. > > Fine in theory, but there are practical problems with lifting all error > message generation up into UI code. > > Lifting errors means we duplicate them in every UI where they can occur. Not if we maintain the description table, so that it can be shared by UIs for common errors. [...] > We may wish to vary the pretty-printing even within a single UI. For > instance, in my "Migration already in progress" example, > QERR_ALREADY_IN_PROGRESS gets pretty-printed specially for command > "migrate". Yet a few more places to change. One more reason to have the generation of the message in a different module.