From: Markus Armbruster <armbru@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: Questionable aspects of QEMU Error's design
Date: Fri, 03 Apr 2020 09:09:27 +0200 [thread overview]
Message-ID: <875zeht594.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <alpine.BSF.2.22.395.2004021716130.78264@zero.eik.bme.hu> (BALATON Zoltan's message of "Thu, 2 Apr 2020 17:28:15 +0200 (CEST)")
BALATON Zoltan <balaton@eik.bme.hu> writes:
> On Thu, 2 Apr 2020, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:
>>> 02.04.2020 12:36, BALATON Zoltan wrote:
[...]
>>>> Not much better. Could it be something like:
[...]
>>>> ERRP_RET(object_property_set_link(cpuobj, OBJECT(&s->cpu_container[i]),
>>>> "memory", errp));
>>>> ERRP_RET(object_property_set_link(cpuobj, OBJECT(s), "idau", errp));
>>>> ERRP_RET(object_property_set_bool(cpuobj, true, "realized", errp));
>>>>
>>>
>>> and turn all
>>>
>>> ret = func(...);
>>> if (ret < 0) {
>>> return ret;
>>> }
>>>
>>> into
>>>
>>> FAIL_RET(func(...))
>>>
>>> ?
>>>
>>> Not a problem to make such macro.. But I think it's a bad idea to turn all the code
>>> into sequence of macro invocations. It's hard to debug and follow.
>>
>> Yes. Hiding control flow in macros is almost always too much magic.
>> There are exceptions, but this doesn't look like one.
>
> I did't like this idea of mine too much either so I agree but I see no
> other easy way to simplify this. If you propose changing function
> return values maybe these should return errp instead of passing it as
> a func parameter? Could that result in simpler code and less macro
> magic needed?
I don't think so. Let's compare a few error handling patterns from
error.h.
* Call a function and receive an error from it:
* Error *err = NULL;
* foo(arg, &err);
* if (err) {
* handle the error...
* }
Making foo() return the error object instead of void looks like an
obvious win:
if (foo(arg)) {
handle the error...
}
Except it does not work, because surely a use of @err is hiding in
"handle the error" (or else we'd leak it). So you actually need
err = foo(arg)
if (err) {
handle the error...
}
All this saves you is initializing @err.
You can save a bit more
if ((err = foo(arg))) {
handle the error...
}
We generally frown upon assignemnts within if controlling expressions.
Next:
* Receive an error and pass it on to the caller:
[...]
* But when all you do with the error is pass it on, please use
* foo(arg, errp);
* for readability.
The obvious conversion
*errp = foo(arg);
is wrong for !errp, errp == &error_fatal, and errp == &error_abort.
You'd need
err = foo(arg);
error_propagate(errp, err);
or, if you're so inclined
error_propagate(errp, foo(arg));
Less legible, and it creates and destroys error objects where the
current method doesn't.
Returning the error object is even less attractive for functions that
now return values.
next prev parent reply other threads:[~2020-04-03 7:10 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 9:02 Questionable aspects of QEMU Error's design Markus Armbruster
2020-04-01 12:10 ` Vladimir Sementsov-Ogievskiy
2020-04-01 12:14 ` Vladimir Sementsov-Ogievskiy
2020-04-01 14:01 ` Alex Bennée
2020-04-01 15:49 ` Markus Armbruster
2020-04-01 15:05 ` Markus Armbruster
2020-04-01 12:44 ` Daniel P. Berrangé
2020-04-01 12:47 ` Vladimir Sementsov-Ogievskiy
2020-04-01 15:34 ` Markus Armbruster
2020-04-01 20:15 ` Peter Maydell
2020-04-02 5:31 ` Vladimir Sementsov-Ogievskiy
2020-04-02 9:36 ` BALATON Zoltan
2020-04-02 14:11 ` Vladimir Sementsov-Ogievskiy
2020-04-02 14:34 ` Markus Armbruster
2020-04-02 15:28 ` BALATON Zoltan
2020-04-03 7:09 ` Markus Armbruster [this message]
2020-04-02 5:54 ` Markus Armbruster
2020-04-02 6:11 ` Vladimir Sementsov-Ogievskiy
2020-04-02 8:11 ` Peter Maydell
2020-04-02 8:49 ` Daniel P. Berrangé
2020-04-02 8:55 ` Markus Armbruster
2020-04-02 14:35 ` Vladimir Sementsov-Ogievskiy
2020-04-02 15:06 ` Markus Armbruster
2020-04-02 17:17 ` Vladimir Sementsov-Ogievskiy
2020-04-03 7:48 ` Markus Armbruster
2020-04-02 18:57 ` Paolo Bonzini
2020-04-02 8:47 ` Daniel P. Berrangé
2020-04-02 9:19 ` Alex Bennée
2020-04-02 14:33 ` Eric Blake
2020-04-04 7:59 ` Markus Armbruster
2020-04-04 10:59 ` Markus Armbruster
2020-04-06 14:05 ` Eduardo Habkost
2020-04-06 14:38 ` Eduardo Habkost
2020-04-06 14:10 ` Daniel P. Berrangé
2020-04-27 15:36 ` Markus Armbruster
2020-04-28 5:20 ` Vladimir Sementsov-Ogievskiy
2020-05-14 7:59 ` Vladimir Sementsov-Ogievskiy
2020-05-15 4:28 ` Markus Armbruster
2020-07-03 7:38 ` Markus Armbruster
2020-07-03 9:07 ` Vladimir Sementsov-Ogievskiy
2020-07-03 12:21 ` 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=875zeht594.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.