Re: Questionable aspects of QEMU Error's design

[Daniel P . Berrangé]

On Thu, Apr 02, 2020 at 08:11:11AM +0000, Peter Maydell wrote:
> On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy
> <address@hidden> wrote:
> > Somehow, in general, especially with long function names and long parameter 
> > lists I prefer
> >
> > ret = func(..);
> > if (ret < 0) {
> >      return ret;
> > }
> 
> Personally I prefer the other approach -- this one has an extra line
> in the source and
> needs an extra local variable.
> 
> > Are you sure that adding a lot of boolean functions is a good idea? I 
> > somehow feel better with more usual int functions with -errno on failure.
> >
> > Bool is a good return value for functions which are boolean by nature: 
> > checks, is something correspond to some criteria. But for reporting an 
> > error I'd prefer -errno.
> 
> When would we want to return an errno? I thought the whole point of the
> Error* was that that was where information about the error was returned.
> If all your callsites are just going to do "if (ret < 0) { ... } then having
> the functions pick an errno value to return is just extra work.

IMHO errno should only be returned if the callers are likely to have 
a genuine need to take action based on the errno in a way that isn't
possible from the Error alone. I expect very few scenarios need that.

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