On Wed, Jun 28, 2017 at 11:05:26AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabk...@redhat.com> writes:
>
> > Rationale
> > ---------
> >
> > I'm often bothered by the fact that we can't write the following:
> >
> > foo(arg, errp);
> > if (*errp) {
> > handle the error...
> > error_propagate(errp, err);
> > }
> >
> > because errp can be NULL.
>
> If foo() additionally returned an indication of success, you could write
>
> if (!foo(arg, errp)) { // assuming foo() returns a bool
> handle the error...
> }
>
> Nicely concise.
>
> For what it's worth, this is how GLib wants GError to be used. We
> deviated from it, and it has turned out to be a self-inflicted wound.
FWIW, I took that approach for the io & crypto layers - except
returning 0 vs -1, rather than true/false, precisely because
it lead to simpler code by not having to use local errors and
propagation.
For added benefit you can potentially then also annotate the
method as __attribute__(return_check) to force the caller
to include a check for error conditions, which is often a
useful compile time protection to have.
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 :|
