qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH 02/46] error: Document Error API usage rules


From: Markus Armbruster
Subject: Re: [PATCH 02/46] error: Document Error API usage rules
Date: Thu, 25 Jun 2020 17:30:09 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Greg Kurz <groug@kaod.org> writes:

> On Wed, 24 Jun 2020 18:43:00 +0200
> Markus Armbruster <armbru@redhat.com> wrote:
>
>> This merely codifies existing practice, with one exception: the rule
>> advising against returning void, where existing practice is mixed.
>> 
>> When the Error API was created, we adopted the (unwritten) rule to
>> return void when the function returns no useful value on success,
>> unlike GError, which recommends to return true on success and false on
>> error then.
>> 
>> When a function returns a distinct error value, say false, a checked
>> call that passes the error up looks like
>> 
>>     if (!frobnicate(..., errp)) {
>>         handle the error...
>>     }
>> 
>> When it returns void, we need
>> 
>>     Error *err = NULL;
>> 
>>     frobnicate(..., &err);
>>     if (err) {
>>         handle the error...
>>         error_propagate(errp, err);
>>     }
>> 
>> Not only is this more verbose, it also creates an Error object even
>> when @errp is null, &error_abort or &error_fatal.
>> 
>> People got tired of the additional boilerplate, and started to ignore
>> the unwritten rule.  The result is confusion among developers about
>> the preferred usage.
>> 
>
> This confusion is reinforced by the fact that the standard pattern:
>
>     error_setg(errp, ...);
>     error_append_hint(errp, ...);
>
> doesn't work when errp is &error_fatal, which is a typical case of
> an invalid command line argument, where it is valuable to suggest
> something sensible to the user but error_setg() exits before we
> could do so.
>
> Fortunately, Vladimir's work will address that and eliminate the
> temptation to workaround the issue with more boilerplate :)

Yes, my work does not obviate Vladimir's at all.  It merely reduce the
number of auto-propagations, hopefully making his patches slightly less
scary.

>> The written rule will hopefully reduce the confusion.
>> 
>> The remainder of this series will update a substantial amount of code
>> to honor the rule.
>> 
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> ---
>
> Reviewed-by: Greg Kurz <groug@kaod.org>

Thanks!




reply via email to

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