All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Michael Roth <mdroth@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH for-2.5] error: Document chained error handling
Date: Tue, 17 Nov 2015 08:11:13 -0700	[thread overview]
Message-ID: <564B4391.50304@redhat.com> (raw)
In-Reply-To: <87egfospna.fsf@blackfin.pond.sub.org>

[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]

On 11/17/2015 06:48 AM, Markus Armbruster wrote:

>> ---
>> based on feedback of my qapi series v5 7/46; doc only, so might
>> be worth having in 2.5
>> ---

>> + *
>> + * In a situation where cleanup must happen even if a first step fails,
>> + * but the cleanup may also set an error, the first error to occur will
>> + * take priority when combined by:
>> + *     Error *err = NULL;
>> + *     action1(arg, errp);
>> + *     action2(arg, &err);
>> + *     error_propagate(errp, err);

Your proposal covers this idiom.

>> + * or by:
>> + *     Error *err = NULL;
>> + *     action1(arg, &err);
>> + *     action2(arg, err ? NULL : &err);
>> + *     error_propagate(errp, err);

This idiom doesn't appear in the current code base, so not documenting
it is okay...

>> + * although the second form is required if any further error handling
>> + * will inspect err to see if all earlier locations succeeded.

...if we instead document how to check if either error happened, but
your version also does that.

>>   */
>>
>>  #ifndef ERROR_H
> 
> Yet another one:
> 
>     *     Error *err = NULL, *local_err = NULL;
>     *     action1(arg, &err);
>     *     action2(arg, &local_err)
>     *     error_propagate(&err, err);

This line should be error_propagate(&err, local_err);

>     *     error_propagate(errp, err);
> 
> Less clever.
> 
> Can we find a single, recommended way to do this?  See below.
> 
> Not mentioned: the obvious
> 
>     action1(arg, errp);
>     action2(arg, errp);
> 
> is wrong, because a non-null Error ** argument must point to a null.  It
> isn't when errp is non-null, and action1() sets an error.  It actually
> fails an assertion in error_setv() when action2() sets an error other
> than with error_propagate().

Indeed, pointing out what we must NOT do is worthwhile.

> 
> The existing how-to comment doesn't spell this out.  It always shows the
> required err = NULL, though.  You can derive "must point to null" from
> the function comments of error_setg() and error_propagate().
> 
> I agree the how-to comment could use a section on accumulating errors.
> Your patch adds one on "accumulate and pass to caller".  Here's my
> attempt:
> 
> diff --git a/include/qapi/error.h b/include/qapi/error.h
> index 4d42cdc..b2362a5 100644
> --- a/include/qapi/error.h
> +++ b/include/qapi/error.h
> @@ -76,6 +76,23 @@
>   * But when all you do with the error is pass it on, please use
>   *     foo(arg, errp);
>   * for readability.
> + *
> + * Receive and accumulate multiple errors (first one wins):
> + *     Error *err = NULL, *local_err = NULL;
> + *     foo(arg, &err);
> + *     bar(arg, &local_err);
> + *     error_propagate(&err, local_err);
> + *     if (err) {
> + *         handle the error...
> + *     }
> + *
> + * Do *not* "optimize" this to
> + *     foo(arg, &err);
> + *     bar(arg, &err); // WRONG!
> + *     if (err) {
> + *         handle the error...
> + *     }
> + * because this may pass a non-null err to bar().

I like that.

>   */
>  
>  #ifndef ERROR_H
> 
> Leaves replacing &err by errp when the value of err isn't needed to the
> reader.  I think that's okay given we've shown it already above.
> 
> What do you think?

I agree; knowing when it is safe to replace &err by errp is already
sufficiently covered in existing text, and limiting this example to a
single point is better.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2015-11-17 15:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 18:20 [Qemu-devel] [PATCH for-2.5] error: Document chained error handling Eric Blake
2015-11-17 13:48 ` Markus Armbruster
2015-11-17 15:11   ` Eric Blake [this message]
2015-11-17 15:36     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=564B4391.50304@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.