All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Bernhard Beschow <shentey@gmail.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	qemu-devel@nongnu.org,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-ppc@nongnu.org, "Hervé Poussineau" <hpoussin@reactos.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>
Subject: Re: [PATCH v4 0/4] hw/audio/pcspk: Inline pcspk_init()
Date: Fri, 03 Nov 2023 09:56:13 +0100	[thread overview]
Message-ID: <87cywr1ahe.fsf@pond.sub.org> (raw)
In-Reply-To: <D0ECDB9D-F04B-46F5-BFE6-94257FB4FF65@gmail.com> (Bernhard Beschow's message of "Sun, 22 Oct 2023 22:23:14 +0000")

Bernhard Beschow <shentey@gmail.com> writes:

> Am 20. Oktober 2023 17:15:04 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>>Unfortunately v2 was merged as commit 40f8214fcd,
>>so adapt v3 to clean the mess.
>>
>>Philippe Mathieu-Daudé (4):
>>  hw/i386/pc: Pass Error** argument to pc_basic_device_init()
>>  hw/i386/pc: Propagate error if HPET device creation failed
>>  hw/i386/pc: Propagate error if PC_SPEAKER device creation failed
>
> I'm not sure if I'd do these first three patches. The reason is that machines don't inherit from DeviceState and therefore don't have canonical methods such as realize() to propagate errors. Propagating the errors in the machine init helper methods seem a bit ad-hoc to me.

The Error interface enables separation of error detection and error
handling.  On detection, we create an Error object, and handling
consumes it.

A function that leaves error handling to its callers generally requires
its callees to leave it, too.  Use of &error_fatal is wrong then.

Even when error handling need not be left to callers, leaving it can
result in simpler or more robust code.

When a function handles errors itself, say by use of &error_fatal or
error_report(), it's only usable in contexts where this handling is
appropriate.

Sometimes the context is obvious enough, and unlikely to change.
Handling directly is fine then, and can be simpler.

When the context isn't that obvious, leaving error handling to callers
liberates you from thinking about the context, and also enables safe
reuse of the function in other contexts.

I think pc_basic_device_init() doesn't *need* the change, as it's
context is obvious enough.  But the change is fine, and if we apply it,
we never have to think about the context again.  Matter of taste.

>>  hw/isa/i82378: Propagate error if PC_SPEAKER device creation failed
>
> The reason I suggested use of `errp` here is that it is already a parameter.

Use of &error_fatal in a function taking @errp is almost always wrong.
The patch fixes an instance of "wrong".



  reply	other threads:[~2023-11-03  8:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20 17:15 [PATCH v4 0/4] hw/audio/pcspk: Inline pcspk_init() Philippe Mathieu-Daudé
2023-10-20 17:15 ` [PATCH v4 1/4] hw/i386/pc: Pass Error** argument to pc_basic_device_init() Philippe Mathieu-Daudé
2023-10-22 16:59   ` Richard Henderson
2023-10-20 17:15 ` [PATCH v4 2/4] hw/i386/pc: Propagate error if HPET device creation failed Philippe Mathieu-Daudé
2023-10-22 17:01   ` Richard Henderson
2023-10-20 17:15 ` [PATCH v4 3/4] hw/i386/pc: Propagate error if PC_SPEAKER " Philippe Mathieu-Daudé
2023-10-22 17:01   ` Richard Henderson
2023-10-20 17:15 ` [PATCH v4 4/4] hw/isa/i82378: " Philippe Mathieu-Daudé
2023-10-22 17:02   ` Richard Henderson
2023-10-22 22:12   ` Bernhard Beschow
2023-10-22 22:23 ` [PATCH v4 0/4] hw/audio/pcspk: Inline pcspk_init() Bernhard Beschow
2023-11-03  8:56   ` Markus Armbruster [this message]
2023-11-08 10:28     ` Philippe Mathieu-Daudé

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=87cywr1ahe.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=hpoussin@reactos.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=shentey@gmail.com \
    /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.