From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: fam@euphon.net, peter.maydell@linaro.org, mst@redhat.com,
codyprime@gmail.com, mark.cave-ayland@ilande.co.uk,
qemu-devel@nongnu.org, armbru@redhat.com, kraxel@redhat.com,
mreitz@redhat.com, qemu-block@nongnu.org, quintela@redhat.com,
david@redhat.com, mdroth@linux.vnet.ibm.com, pasic@linux.ibm.com,
borntraeger@de.ibm.com, marcandre.lureau@redhat.com,
rth@twiddle.net, farman@linux.ibm.com, groug@kaod.org,
dgilbert@redhat.com, alex.williamson@redhat.com,
qemu-arm@nongnu.org, stefanha@redhat.com, jsnow@redhat.com,
david@gibson.dropbear.id.au,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
cohuck@redhat.com, qemu-s390x@nongnu.org, sundeep.lkml@gmail.com,
qemu-ppc@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC] error: auto propagated local_err
Date: Thu, 19 Sep 2019 11:09:03 +0100 [thread overview]
Message-ID: <20190919100903.GF20217@redhat.com> (raw)
In-Reply-To: <20190919091720.GB10163@localhost.localdomain>
On Thu, Sep 19, 2019 at 11:17:20AM +0200, Kevin Wolf wrote:
> Am 18.09.2019 um 19:10 hat Eric Blake geschrieben:
> > On 9/18/19 8:02 AM, Vladimir Sementsov-Ogievskiy wrote:
> > > + */
> > > +#define MAKE_ERRP_SAFE(errp) \
> > > +g_auto(ErrorPropagationStruct) (__auto_errp_prop) = {.errp = (errp)}; \
> > > +if ((errp) == NULL || *(errp) == error_abort || *(errp) == error_fatal) { \
> > > + (errp) = &__auto_errp_prop.local_err; \
> > > +}
> >
> > Not written to take a trailing semicolon in the caller.
> >
> > You could even set __auto_errp_prop unconditionally rather than trying
> > to reuse incoming errp (the difference being that error_propagate() gets
> > called more frequently).
>
> I think this difference is actually a problem.
>
> When debugging things, I hate error_propagate(). It means that the Error
> (specifically its fields src/func/line) points to the outermost
> error_propagate() rather than the place where the error really happened.
> It also makes error_abort completely useless because at the point where
> the process gets aborted, the interesting information is already lost.
Yeah, that is very frustrating. For personal development you can eventually
figure it out, but with customer support requests, all you get is the
stack trace and you've no core file to investigate, so you're stuck.
IOW, as a general principle, we should strive to minimize the usage
of error propagate.
The key reason why we typically need the propagate calls, is because
we allow the passed in Error **errp parameter to be NULL, while at the
same time we want to inspect it to see if its contents are non-NULL
to detect failure. I venture to suggest that this is flawed API
design on our part. We should not need to inspect the error object
to see if a method call fails - the return value can be used for
this purpose.
IOW, instead of this pattern with typically 'void' methods
extern void somemethod(Error **errp);
void thismethod(Error **errp) {
Error *local_err = NULL;
...
somemethod(&local_err);
if (local_err) {
error_propagate(errp, local_err);
return;
}
...
}
We should be preferring
extern int somemethod(Error **errp);
int thismethod(Error **errp) {
...
if (somemethod(errp) < 0) {
return -1;
}
...
}
ie only using the Error object to bubble up the *details* of
the error, not as the mechanism for finding if an error occurred.
There is of course a downside with this approach, in that a
method might set 'errp' but return 0, or not set 'errp' but
return -1. I think this is outweighed by the simpler code
pattern overall though.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2019-09-19 10:12 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 13:02 [Qemu-devel] [RFC] error: auto propagated local_err Vladimir Sementsov-Ogievskiy
2019-09-18 17:10 ` Eric Blake
2019-09-18 17:46 ` Vladimir Sementsov-Ogievskiy
2019-09-18 18:05 ` Eric Blake
2019-09-18 18:32 ` Eric Blake
2019-09-19 6:47 ` Vladimir Sementsov-Ogievskiy
2019-09-19 13:29 ` Eric Blake
2019-09-19 9:17 ` Kevin Wolf
2019-09-19 9:47 ` Vladimir Sementsov-Ogievskiy
2019-09-19 10:09 ` Daniel P. Berrangé [this message]
2019-09-19 10:21 ` Vladimir Sementsov-Ogievskiy
2019-09-19 11:55 ` Daniel P. Berrangé
2019-09-19 12:00 ` Vladimir Sementsov-Ogievskiy
2019-09-19 13:03 ` Kevin Wolf
2019-09-19 13:17 ` Vladimir Sementsov-Ogievskiy
2019-09-19 13:44 ` Eric Blake
2019-09-19 13:40 ` Eric Blake
2019-09-19 14:13 ` Vladimir Sementsov-Ogievskiy
2019-09-19 14:26 ` Eric Blake
2019-09-19 14:30 ` Vladimir Sementsov-Ogievskiy
2019-09-19 14:44 ` Eric Blake
2019-09-19 14:49 ` Daniel P. Berrangé
2019-09-19 15:24 ` Eric Blake
2019-09-19 15:37 ` Vladimir Sementsov-Ogievskiy
2019-09-19 15:50 ` Daniel P. Berrangé
2019-09-19 16:16 ` Vladimir Sementsov-Ogievskiy
2019-09-19 16:51 ` Daniel P. Berrangé
2019-09-20 12:58 ` Eric Blake
2019-09-19 15:12 ` Vladimir Sementsov-Ogievskiy
2019-09-19 14:34 ` Kevin Wolf
2019-09-19 1:54 ` [Qemu-devel] " no-reply
2019-09-19 7:32 ` David Hildenbrand
2019-09-19 7:41 ` Vladimir Sementsov-Ogievskiy
2019-09-19 7:53 ` David Hildenbrand
2019-09-19 8:20 ` Vladimir Sementsov-Ogievskiy
2019-09-19 8:23 ` David Hildenbrand
2019-09-19 8:59 ` Greg Kurz
2019-09-19 9:28 ` Vladimir Sementsov-Ogievskiy
2019-09-19 10:08 ` Greg Kurz
2019-09-19 8:59 ` Max Reitz
2019-09-19 9:14 ` Vladimir Sementsov-Ogievskiy
2019-09-19 9:33 ` Max Reitz
2019-09-19 10:03 ` Vladimir Sementsov-Ogievskiy
2019-09-19 11:52 ` Max Reitz
2019-09-20 11:46 ` Vladimir Sementsov-Ogievskiy
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=20190919100903.GF20217@redhat.com \
--to=berrange@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=codyprime@gmail.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=fam@euphon.net \
--cc=farman@linux.ibm.com \
--cc=groug@kaod.org \
--cc=jsnow@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.com \
--cc=sundeep.lkml@gmail.com \
--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 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).