From: Paolo Bonzini <pbonzini@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Laszlo Ersek <lersek@redhat.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qemu-sockets: Fix assertion failure
Date: Wed, 06 Mar 2013 17:43:11 +0100 [thread overview]
Message-ID: <5137721F.7060503@redhat.com> (raw)
In-Reply-To: <87a9qg5xjf.fsf@blackfin.pond.sub.org>
Il 06/03/2013 16:59, Markus Armbruster ha scritto:
>> >
>> > I don't really understand the difference. As long as the function
>> > doesn't depend on the Error object to be present (which it doesn't),
>> > isn't it semantically exactly the same?
> I guess it is in this case (I didn't call your patch wrong). However, I
> figure that as soon as we go beyond utterly trivial with errors, it's
> advisable to put them in local variables, and error_propagate() to the
> parameter only at the end. Messing around with errp parameters directly
> feels error-prone, and I'm afraid even correct messing could easily lead
> to incorrect messing, when folks imitate it without really understanding
> what they're doing.
Yes, that's my thought more or less. However, the possibilities are:
1) asserting that there is no error. We hardly ever do this, and it's
not clear to me that we should start. It would introduce one more
error-propagation idiom, and more confusion.
2) do nothing if there is an error. This is what for example the QAPI
visitors do.
3) what Laszlo suggested. However, it is almost certainly a bug to call
this function with a pre-existing error, because this function has quite
"strong" side effects. Hence this might mask a bug and leave pending
connections.
4) just your patch. This is just as wrong as (3) if there was a
pre-existing error, and it also overwrites the pre-existing error;
harder to debug, and inconsistent with functions using the local variables.
None is optimal, but (2) seems the best.
Paolo
> Yes, extra local variables make the error propagation code even bulkier.
> No, I don't like it any more than you do.
next prev parent reply other threads:[~2013-03-06 16:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 10:48 [Qemu-devel] [PATCH] qemu-sockets: Fix assertion failure Kevin Wolf
2013-03-06 11:04 ` Paolo Bonzini
2013-03-06 11:11 ` Kevin Wolf
2013-03-06 14:46 ` Laszlo Ersek
2013-03-06 15:04 ` Paolo Bonzini
2013-03-06 15:19 ` Kevin Wolf
2013-03-06 15:38 ` Laszlo Ersek
2013-03-06 15:47 ` Kevin Wolf
2013-03-06 16:04 ` Laszlo Ersek
2013-03-06 15:59 ` Markus Armbruster
2013-03-06 16:43 ` Paolo Bonzini [this message]
2013-03-14 14:57 ` [Qemu-devel] [RFC PATCH] qemu-socket: Use local error variable Kevin Wolf
2013-03-14 15:52 ` Laszlo Ersek
2013-03-15 8:37 ` Kevin Wolf
2013-03-15 16:55 ` Laszlo Ersek
2013-03-15 17:55 ` Kevin Wolf
2013-03-15 18:39 ` Laszlo Ersek
2013-03-19 20:34 ` [Qemu-devel] [PATCH] qemu-sockets: Fix assertion failure Luiz Capitulino
2013-03-20 8:39 ` Kevin Wolf
2013-03-20 12:57 ` Luiz Capitulino
2013-03-20 13:37 ` Kevin Wolf
2013-03-20 13:52 ` Luiz Capitulino
2013-03-06 15:05 ` Markus Armbruster
2013-03-06 15:05 ` [Qemu-devel] Error ** parameter conventions (was: [PATCH] qemu-sockets: Fix assertion failure) Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5137721F.7060503@redhat.com \
--to=pbonzini@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).