Stefan Hajnoczi <address@hidden> writes:
On Wed, Jul 26, 2017 at 08:02:53PM +0800, Mao Zhongyi wrote:
When the function no success value to transmit, it usually make the
function return void. It has turned out not to be a success, because
it means that the extra local_err variable and error_propagate() will
be needed. It leads to cumbersome code, therefore, transmit success/
failure in the return value is worth.
So fix the return type of blkconf_apply_backend_options(),
blkconf_geometry() and virtio_blk_data_plane_create() to avoid it.
Cc: John Snow <address@hidden>
Cc: Kevin Wolf <address@hidden>
Cc: Max Reitz <address@hidden>
Cc: Stefan Hajnoczi <address@hidden>
Signed-off-by: Mao Zhongyi <address@hidden>
---
hw/block/block.c | 21 ++++++++++++---------
hw/block/dataplane/virtio-blk.c | 16 +++++++++-------
hw/block/dataplane/virtio-blk.h | 6 +++---
include/hw/block/block.h | 10 +++++-----
4 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/hw/block/block.c b/hw/block/block.c
index 27878d0..717bd0e 100644
--- a/hw/block/block.c
+++ b/hw/block/block.c
@@ -51,8 +51,8 @@ void blkconf_blocksizes(BlockConf *conf)
}
}
-void blkconf_apply_backend_options(BlockConf *conf, bool readonly,
- bool resizable, Error **errp)
+int blkconf_apply_backend_options(BlockConf *conf, bool readonly,
+ bool resizable, Error **errp)
I'm not a fan of these changes because it makes inconsistencies between
the return value and the errp argument possible (e.g. returning success
but setting errp, or returning failure without setting errp).
Opinions and practice vary on this one, and we've discussed the
tradeoffs a few times.
Having both an Error parameter and an error return value poses the
question whether the two agree. When there's no success value to
transmit, you avoid the problem by making the function return void. The
problem remains for all the function that return a value on success, and
therefore must return some error value on failure. A related problem
even remains for functions returning void: consistency between side
effects and the Error parameter.
Returning void leads to awkward boilerplate:
Error err = NULL;
foo(..., err);
if (err) {
error_propagate(errp, err);
... bail out ...
}
Compare:
if (!foo(..., errp)) {
... bail out ...
}
Much easier on the eyes.
For what it's worth, GLib wants you to transmit success / failure in the
return value, too:
https://developer.gnome.org/glib/unstable/glib-Error-Reporting.html#gerror-rules
Plenty of older code returns void, some newer code doesn't, because
returning void is just too awkward. We willfully deviated from GLib's
convention, and we're now paying the price.
See also
Subject: Re: [RFC 00/15] Error API: Flag errors in *errp even if errors are
being ignored
Message-ID: <address@hidden>
https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06191.html
If you really want to do this please use bool as the return type instead
of int. int can be abused to return error information that should
really be in the Error object.
For what it's worth, GLib wants bool[*]. Let's stick to that unless we
have a compelling reason to differ.
[*] Except being GLib, it wants its very own homemade version of bool.
Which is inferior to stdbool.h's in pretty much every conceivable way.