From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjIwm-000612-Se for qemu-devel@nongnu.org; Thu, 03 Sep 2009 16:30:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjIwh-0005zz-Ph for qemu-devel@nongnu.org; Thu, 03 Sep 2009 16:30:20 -0400 Received: from [199.232.76.173] (port=59158 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjIwh-0005zr-Fx for qemu-devel@nongnu.org; Thu, 03 Sep 2009 16:30:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15090) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MjIwg-0003bp-SS for qemu-devel@nongnu.org; Thu, 03 Sep 2009 16:30:15 -0400 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n83KUBlR009105 for ; Thu, 3 Sep 2009 16:30:11 -0400 Received: from zweiblum.home.kraxel.org (vpn1-4-229.ams2.redhat.com [10.36.4.229]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n83KU9g8024606 for ; Thu, 3 Sep 2009 16:30:10 -0400 Message-ID: <4AA02750.8000005@redhat.com> Date: Thu, 03 Sep 2009 22:30:08 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC 0/5] Monitor handlers convertion to QObject References: <1251987859-20254-1-git-send-email-lcapitulino@redhat.com> In-Reply-To: <1251987859-20254-1-git-send-email-lcapitulino@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, > Some people have suggested us to define errors codes, but I dislike this > because I have the impression we will end up defining errors per-handlers, > which is a lot of work and more protocol definitions to maintain. What about error messages? I've recently added some infrastructure for error messages: qemu_error() + friends. Intention is to direct error messages to the correct place, especially for code which can be called from multiple paths. Device creation for example can be triggered by command line (errors should go to stderr) or via hotplug monitor commands (errors should go to the monitor). You might want to add a third error sink which stuffs error messages into a Qstring, so you can pass them along as Qobject without the code emitting the error message knowing anything about it. > Another issue in this subject is that sometimes we will have to do > a not so small refactor to get the proper error code. I mean, sometimes > the functions which the handlers call return void, and those functions in > turn call other functions which also return void. This seem to be the > case of do_balloon(), for example. There are also a few places which call exit(1) on error. Which is ok when something goes wrong while creating the virtual machine, but not when some monitor command failed ... > A possible solution is to only return error when it's easy, otherwise we > could always return 0 (which is what we have today), the problem though > is that changing this in the future will cause trouble. Serious code audit is more work initially, but I think we well be very happy we did it in the long run ... cheers, Gerd