All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] mirror: drop local_err in mirror_complete
Date: Sat, 19 Oct 2013 10:50:31 +0200	[thread overview]
Message-ID: <526247D7.8050404@redhat.com> (raw)
In-Reply-To: <52617702.1080906@redhat.com>

Il 18/10/2013 19:59, Max Reitz ha scritto:
> Someone obviously intended some purpose for it, so even if it doesn't
> make a difference now (and my RFC is unneeded), I'd still use it to
> propagate errors (instead of passing the error pointer). My point being
> that there *is* a function for propagating errors and I think we should
> therefore use it. The current qemu code seems to alternate between the
> two alternatives, although using error_propagate seems more common to me
> (at least, that was the result when I looked through the code trying to
> decide whether to use it or not).
> 
> Generally, we need a proper discussion about whether error_propagate is
> obsolete or not. Afterwards, we can adapt the current codebase to the
> result of that discussion; but until then, I oppose changing existing
> code without actual need to do so but personal preference.

error_propagate is not obsolete.  It is particularly pervasive in
generated code.

You can and should skip error_propagate if you are tail-calling another
function.  In this case, the extra if/error_propagate pair is useless,
makes the code less clear and adds 3-4 useless lines of code.

If you have an alternative way to see whether an error occurred
(typically based on the return value: <0 if it is int, NULL if it is a
pointer), it is fine to use it instead of error_propagate, because
error_propagate adds some complexity to the logic.  It is also fine to
use error_propagate; whatever makes the code simpler.

However, the converse is not true.  If you have a function that returns
void and takes an Error*, it is not okay to make it return int or bool
for the sake of avoiding error_propagate.

There are also cases where you have a return value, but you cannot use
it to ascertain whether an error occurred.  For example, NULL may be a
valid return value even when no error occurs.  In such case, you have to
use error_propagate.

In the end, I agree with Kevin: "If in doubt, use local_err".  Tail
calls should be the only case where local_err is clearly unnecessary,
any other case needs to be considered specifically.

Paolo

  parent reply	other threads:[~2013-10-19  8:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15  2:23 [Qemu-devel] [PATCH v2] mirror: drop local_err in mirror_complete Fam Zheng
2013-10-15  3:05 ` Eric Blake
2013-10-15  3:12   ` Fam Zheng
2013-10-16 18:56 ` Max Reitz
2013-10-17 12:49   ` Stefan Hajnoczi
2013-10-17 13:00     ` Kevin Wolf
2013-10-18  8:51       ` Fam Zheng
2013-10-18 17:59         ` Max Reitz
2013-10-19  8:05           ` Kevin Wolf
2013-10-19 20:02             ` Max Reitz
2013-10-19  8:50           ` Paolo Bonzini [this message]
2013-10-18  8:52       ` Stefan Hajnoczi
2013-10-17 12:51   ` Stefan Hajnoczi

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=526247D7.8050404@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.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.