From: Markus Armbruster <armbru@redhat.com>
To: bibo mao <maobibo@loongson.cn>
Cc: Song Gao <gaosong@loongson.cn>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 2/3] hw/loongarch/virt: Remove unnecessary NULL pointer checking
Date: Fri, 14 Mar 2025 09:56:37 +0100 [thread overview]
Message-ID: <87a59ot2gq.fsf@pond.sub.org> (raw)
In-Reply-To: <fc8a893c-9ff5-ad44-812a-66dd0f163269@loongson.cn> (bibo mao's message of "Fri, 14 Mar 2025 14:28:27 +0800")
bibo mao <maobibo@loongson.cn> writes:
> The question how to use error_propagate() comparing with error_setg() since there is such API. :)
error_propagate() should be mostly avoided in new code. It still exists
because plenty of old code uses it. It can also be used to keep only
first of several errors, but that's rarely a good idea.
There's usage advice in include/qapi/error.h's big comment. Relevant
parts for your convenience:
* = Passing errors around =
*
* Errors get passed to the caller through the conventional @errp
* parameter.
*
* Create a new error and pass it to the caller:
* error_setg(errp, "situation normal, all fouled up");
*
* Call a function, receive an error from it, and pass it to the caller
* - when the function returns a value that indicates failure, say
* false:
* if (!foo(arg, errp)) {
* handle the error...
* }
* - when it does not, say because it is a void function:
* ERRP_GUARD();
* foo(arg, errp);
* if (*errp) {
* handle the error...
* }
* More on ERRP_GUARD() below.
*
* Code predating ERRP_GUARD() still exists, and looks like this:
* Error *err = NULL;
* foo(arg, &err);
* if (err) {
* handle the error...
* error_propagate(errp, err); // deprecated
* }
* Avoid in new code. Do *not* "optimize" it to
* foo(arg, errp);
* if (*errp) { // WRONG!
* handle the error...
* }
* because errp may be NULL without the ERRP_GUARD() guard.
*
* But when all you do with the error is pass it on, please use
* foo(arg, errp);
* for readability.
[...]
* Pass an existing error to the caller:
* error_propagate(errp, err);
* This is rarely needed. When @err is a local variable, use of
* ERRP_GUARD() commonly results in more readable code.
*
* Pass an existing error to the caller with the message modified:
* error_propagate_prepend(errp, err,
* "Could not frobnicate '%s': ", name);
* This is more concise than
* error_propagate(errp, err); // don't do this
* error_prepend(errp, "Could not frobnicate '%s': ", name);
* and works even when @errp is &error_fatal.
*
* Receive and accumulate multiple errors (first one wins):
* Error *err = NULL, *local_err = NULL;
* foo(arg, &err);
* bar(arg, &local_err);
* error_propagate(&err, local_err);
* if (err) {
* handle the error...
* }
*
* Do *not* "optimize" this to
* Error *err = NULL;
* foo(arg, &err);
* bar(arg, &err); // WRONG!
* if (err) {
* handle the error...
* }
* because this may pass a non-null err to bar().
*
* Likewise, do *not*
* Error *err = NULL;
* if (cond1) {
* error_setg(&err, ...);
* }
* if (cond2) {
* error_setg(&err, ...); // WRONG!
* }
* because this may pass a non-null err to error_setg().
Questions?
next prev parent reply other threads:[~2025-03-14 8:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 9:13 [PATCH 0/3] target/loongarch: Solve some issues reported from coccinelle Bibo Mao
2025-03-13 9:13 ` [PATCH 1/3] target/loongarch: Return directly when detect KVM disabled features Bibo Mao
2025-03-13 10:26 ` Markus Armbruster
2025-03-13 11:17 ` bibo mao
2025-03-13 9:13 ` [PATCH 2/3] hw/loongarch/virt: Remove unnecessary NULL pointer checking Bibo Mao
2025-03-13 10:32 ` Markus Armbruster
2025-03-13 11:22 ` bibo mao
2025-03-14 2:27 ` bibo mao
2025-03-14 5:38 ` Markus Armbruster
2025-03-14 6:28 ` bibo mao
2025-03-14 6:58 ` bibo mao
2025-03-14 8:56 ` Markus Armbruster [this message]
2025-03-13 9:13 ` [PATCH 3/3] target/loongarch: Remove unnecessary temporary variable assignment Bibo Mao
2025-03-13 10:33 ` Markus Armbruster
2025-03-13 10:41 ` Philippe Mathieu-Daudé
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=87a59ot2gq.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=gaosong@loongson.cn \
--cc=jiaxun.yang@flygoat.com \
--cc=maobibo@loongson.cn \
--cc=pbonzini@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 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.