qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 00/15] Error API: Flag errors in *errp even if err


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [RFC 00/15] Error API: Flag errors in *errp even if errors are being ignored
Date: Thu, 29 Jun 2017 15:18:05 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

On Thu, Jun 29, 2017 at 03:39:58PM +0200, Paolo Bonzini wrote:
> On 28/06/2017 11:05, Markus Armbruster wrote:
> > 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.
> > 
> 
> I find Eduardo's proposal better.  With GLib's way it's easy to confuse
> functions that return 0/-1, 0/-errno, TRUE/FALSE, FALSE/TRUE or
> NULL/non-NULL.

NB, glib basically standardizes on just FALSE/TRUE and NULL/non-NULL,
avoiding anything returning -1, or errno values, so in their usage
there isn't really any confusion.

QEMU of course has lots of pre-existing code, but we could at least
declare a preferred approach, and work towards it.

Having the return value indicate error is slightly shorter, and it
avoids all the blackmagic with special Error values in Eduardo's
series. Most usefully, it lets you use __attribute__(return_check)
to get compile time checking of callers who forget to check for
failure.

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]