From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NfZez-0003Mc-UM
	for qemu-devel@nongnu.org; Thu, 11 Feb 2010 09:04:50 -0500
Received: from [199.232.76.173] (port=41107 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NfZez-0003Lg-AK
	for qemu-devel@nongnu.org; Thu, 11 Feb 2010 09:04:49 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <anthony@codemonkey.ws>) id 1NfZex-0008GK-Ip
	for qemu-devel@nongnu.org; Thu, 11 Feb 2010 09:04:48 -0500
Received: from mail-iw0-f194.google.com ([209.85.223.194]:60827)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NfZex-0008G5-12
	for qemu-devel@nongnu.org; Thu, 11 Feb 2010 09:04:47 -0500
Received: by iwn32 with SMTP id 32so2115623iwn.14
	for <qemu-devel@nongnu.org>; Thu, 11 Feb 2010 06:04:46 -0800 (PST)
Message-ID: <4B740E7A.9060105@codemonkey.ws>
Date: Thu, 11 Feb 2010 08:04:42 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH v0 00/21]: Monitor: improve handlers error
	handling
References: <1265853007-27300-1-git-send-email-lcapitulino@redhat.com>
In-Reply-To: <1265853007-27300-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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: qemu-devel@nongnu.org, armbru@redhat.com

On 02/10/2010 07:49 PM, Luiz Capitulino wrote:
>   Hi there,
>
>   When I started converting handlers to the QObject style, I thought that
> returning an error code wouldn't be needed. That is, we have an error object
> already, so if the handler returns the error object it has failed, otherwise
> it has succeeded.
>
>   This was also very convenient, because handlers have never returned an error
> code, and thus it would be easier to add a call to qemu_error_new() in the
> right place instead of returning error codes.
>
>   Turns out we need both. Actually, I should not have abused the error object
> this way because (as Markus says) this is too fragile and we can end up
> reporting bogus errors to clients (among other problems).
>
>   The good news is that it's easy to fix.
>
>   All we have to do is to change cmd_new() (the handler callback) to return an
> error code and convert existing QObject handlers to it. This series does that
> and most of the patches are really straightforward conversions.
>
>   Additionally, Markus has designed an excellent debug mechanism for QMP, which
> is implemented by the last patches in this series, and will allow us to catch
> important QObject conversion and error handling bugs in handlers.
>    

Instead of returning -1, would it make more sense to return an error 
object?  If fact, why not drop ret_data as a passed in parameter, and 
just always return either the result or an error object.

Regards,

Anthony Liguori

>   Thanks.
>
>
>
>