From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Questionable aspects of QEMU Error's design
Date: Wed, 01 Apr 2020 11:02:11 +0200 [thread overview]
Message-ID: <87o8sblgto.fsf@dusky.pond.sub.org> (raw)
QEMU's Error was patterned after GLib's GError. Differences include:
* &error_fatal, &error_abort for convenience
* Error can optionally store hints
* Pointlessly different names: error_prepend() vs. g_error_prefix() and
so forth *shrug*
* Propagating errors
Thanks to Vladimir, we'll soon have "auto propagation", which is less
verbose and less error-prone.
* Accumulating errors
error_propagate() permits it, g_propagate_error() does not[*].
I believe this feature is used rarely. Perhaps we'd be better off
without it. The problem is identifying its uses. If I remember
correctly, Vladimir struggled with that for his "auto propagation"
work.
Perhaps "auto propagation" will reduce the number of manual
error_propagate() to the point where we can identify accumulations.
Removing the feature would become feasible then.
* Distinguishing different errors
Where Error has ErrorClass, GError has Gquark domain, gint code. Use
of ErrorClass other than ERROR_CLASS_GENERIC_ERROR is strongly
discouraged. When we need callers to distinguish errors, we return
suitable error codes separately.
* Return value conventions
Common: non-void functions return a distinct error value on failure
when such a value can be defined. Patterns:
- Functions returning non-null pointers on success return null pointer
on failure.
- Functions returning non-negative integers on success return a
negative error code on failure.
Different: GLib discourages void functions, because these lead to
awkward error checking code. We have tons of them, and tons of
awkward error checking code:
Error *err = NULL;
frobnicate(arg, &err);
if (err) {
... recover ...
error_propagate(errp, err);
}
instead of
if (!frobnicate(arg, errp))
... recover ...
}
Can also lead to pointless creation of Error objects.
I consider this a design mistake. Can we still fix it? We have more
than 2000 void functions taking an Error ** parameter...
Transforming code that receives and checks for errors with Coccinelle
shouldn't be hard. Transforming code that returns errors seems more
difficult. We need to transform explicit and implicit return to
either return true or return false, depending on what we did to the
@errp parameter on the way to the return. Hmm.
[*] According to documentation; the code merely calls g_warning() then,
in typical GLib fashion.
next reply other threads:[~2020-04-01 9:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 9:02 Markus Armbruster [this message]
2020-04-01 12:10 ` Questionable aspects of QEMU Error's design 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
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=87o8sblgto.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--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.