[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questionable aspects of QEMU Error's design
From: |
Markus Armbruster |
Subject: |
Re: Questionable aspects of QEMU Error's design |
Date: |
Thu, 02 Apr 2020 10:55:27 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Peter Maydell <address@hidden> writes:
> 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.
Me too, except when func(...) is so long that
if (func(...) < 0) {
becomes illegible like
if (func(... yadda, yadda,
yadda, ...) < 0) {
Then an extra variable can improve things.
>> 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.
0/-1 vs. true/false is a matter of convention. Lacking convention, it's
a matter of taste.
0/-1 vs. 0/-errno depends on the function and its callers. When -errno
enables callers to distinguish failures in a sane and simple way, use
it. When -errno feels "natural", I'd say feel free to use it even when
all existing callers only check < 0.
When you return non-null/null or true/false on success/error, neglecting
to document that in a function contract can perhaps be tolerated; you're
using the return type the common, obvious way. But when you return 0/-1
or 0/-errno, please spell it out. I've seen too many "Operation not
permitted" that were actually -1 mistaken for -EPERM. Also too many
functions that return -1 for some failures and -errno for others.
- Re: Questionable aspects of QEMU Error's design, (continued)
- Re: Questionable aspects of QEMU Error's design, Vladimir Sementsov-Ogievskiy, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, BALATON Zoltan, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Vladimir Sementsov-Ogievskiy, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, BALATON Zoltan, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/03
Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Vladimir Sementsov-Ogievskiy, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Peter Maydell, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Daniel P . Berrangé, 2020/04/02
- Re: Questionable aspects of QEMU Error's design,
Markus Armbruster <=
- Re: Questionable aspects of QEMU Error's design, Vladimir Sementsov-Ogievskiy, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Vladimir Sementsov-Ogievskiy, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/03
Re: Questionable aspects of QEMU Error's design, Paolo Bonzini, 2020/04/02
Re: Questionable aspects of QEMU Error's design, Daniel P . Berrangé, 2020/04/02
Re: Questionable aspects of QEMU Error's design, Alex Bennée, 2020/04/02
Re: Questionable aspects of QEMU Error's design, Eric Blake, 2020/04/02
Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/04