qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
	Markus Armbruster <armbru@redhat.com>,
	afaerber@suse.de, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH v1 0/5] Add error_abort and associated cleanups
Date: Thu, 5 Dec 2013 16:32:28 +0100	[thread overview]
Message-ID: <20131205163228.4700f3cc@nial.usersys.redhat.com> (raw)
In-Reply-To: <52A05767.60703@redhat.com>

On Thu, 05 Dec 2013 11:37:27 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 03/12/2013 21:33, Igor Mammedov ha scritto:
> > I'm sorry for hijacking thread, but that actually an issue that started an
> > original discussion.
> > Where void returning QOM API functions are used with NULL, without any chance
> > to detect that error happened. So abusing NULL errp in this functions
> > might lead to hard to find runtime errors.
> > I think Eric's suggestion was to enforce passing non NULL errp and let caller
> > to deal with error gracefully so that above mentioned misuse was impossible.
> > Why is ignoring errors from "void foo(...)" like API considered acceptable?
> 
> See http://permalink.gmane.org/gmane.comp.emulators.qemu/243779
> 
> > * Peter's alternative
> >   + self-documenting
> >   + consistent
> >   + predictable
> 
> I'll add another small advantage which is fewer SLOC.
There is not argument against Peter's approach at all,
question is what do we do with NULL errp in void API functions?

> 
> > * make Error* mandatory for all void functions
one more advantage:
+ not need to pepper every property setter/getter with local_error + error_propagate(),
  i.e. reduced code duplication.

> >   + consistent
> >   + almost predictable (because in C you can ignore return values)
there is no return values from void functions.

> >   - not necessarily does the right thing (e.g. cleanup functions)
we can pass &error_abort instead of NULL there if we don't care. If there will
be error it would mean something went horribly wrong and perhaps code
should care if error happens there.

for special cases we could invent &ignore_error if there will be real need for it.

> >   - requires manual effort to abide to the policy
with assert inside API there is no manual effort. But as Marcus
noted these errors will be only runtime detectable :(

> 
> Better wording of the last: a missing &error_abort is easier to spot
> than a missing assert_no_error(errp).
> 
> Paolo

  reply	other threads:[~2013-12-05 15:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-03  5:49 [Qemu-devel] [RFC PATCH v1 0/5] Add error_abort and associated cleanups Peter Crosthwaite
2013-12-03  5:49 ` [Qemu-devel] [RFC PATCH v1 1/5] error: Add error_abort Peter Crosthwaite
2013-12-03  5:50 ` [Qemu-devel] [RFC PATCH v1 2/5] hw: Remove assert_no_error usages Peter Crosthwaite
2013-12-03  9:35   ` Markus Armbruster
2013-12-03 10:04     ` Peter Crosthwaite
2013-12-03  5:51 ` [Qemu-devel] [RFC PATCH v1 3/5] target-i386: Remove assert_no_error usage Peter Crosthwaite
2013-12-03  5:51 ` [Qemu-devel] [RFC PATCH v1 4/5] qemu-option: Remove qemu_opts_create_nofail Peter Crosthwaite
2013-12-03  9:42   ` Markus Armbruster
2013-12-03 10:17     ` Peter Crosthwaite
2013-12-03 10:44       ` Markus Armbruster
2013-12-04  6:45     ` Peter Crosthwaite
2013-12-03  5:52 ` [Qemu-devel] [RFC PATCH v1 5/5] qerror: Remove assert_no_error() Peter Crosthwaite
2013-12-03  9:44 ` [Qemu-devel] [RFC PATCH v1 0/5] Add error_abort and associated cleanups Markus Armbruster
2013-12-03 11:49   ` Igor Mammedov
2013-12-03 11:57   ` Paolo Bonzini
2013-12-03 12:03     ` Peter Crosthwaite
2013-12-03 12:58   ` Eric Blake
2013-12-03 13:53     ` Markus Armbruster
2013-12-03 20:33       ` Igor Mammedov
2013-12-03 20:43         ` Eric Blake
2013-12-04  9:11           ` Markus Armbruster
2013-12-04 14:46             ` Eric Blake
2013-12-05 10:37         ` Paolo Bonzini
2013-12-05 15:32           ` Igor Mammedov [this message]
2013-12-05 15:59             ` Paolo Bonzini

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=20131205163228.4700f3cc@nial.usersys.redhat.com \
    --to=imammedo@redhat.com \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.crosthwaite@xilinx.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).