* [Qemu-devel] error reporting in functions
@ 2016-10-12 15:47 Vladimir Sementsov-Ogievskiy
2016-10-12 20:55 ` Eric Blake
0 siblings, 1 reply; 3+ messages in thread
From: Vladimir Sementsov-Ogievskiy @ 2016-10-12 15:47 UTC (permalink / raw)
To: qemu-devel
HI all!
My questions is: what are general recommendations in Qemu for return
code, if we have Error **errp?
What should I prefer: errp, duplicated by int return code, or void
functions with errp?
void + errp seems good, just to not duplicate things. But it has a
disadvantage of necessity of "local_err" and "error_propagate" in caller
function, if its behaviour depends on callee function success...
--
Best regards,
Vladimir
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] error reporting in functions
2016-10-12 15:47 [Qemu-devel] error reporting in functions Vladimir Sementsov-Ogievskiy
@ 2016-10-12 20:55 ` Eric Blake
2016-10-13 6:39 ` Markus Armbruster
0 siblings, 1 reply; 3+ messages in thread
From: Eric Blake @ 2016-10-12 20:55 UTC (permalink / raw)
To: Vladimir Sementsov-Ogievskiy, qemu-devel, Markus Armbruster
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]
On 10/12/2016 10:47 AM, Vladimir Sementsov-Ogievskiy wrote:
> HI all!
>
> My questions is: what are general recommendations in Qemu for return
> code, if we have Error **errp?
> What should I prefer: errp, duplicated by int return code, or void
> functions with errp?
Markus has already had several threads commenting on this very topic in
the past. A lot of code uses void return, but some newer code is using
an int return for simplifying the call-sites (and glib prefers the int
rather than void return, as well). Markus was playing with a Coccinelle
script to see how painful a bulk-conversion of the code base would be,
but it is probably stalled behind more pressing work at the moment.
>
> void + errp seems good, just to not duplicate things. But it has a
> disadvantage of necessity of "local_err" and "error_propagate" in caller
> function, if its behaviour depends on callee function success...
>
--
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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] error reporting in functions
2016-10-12 20:55 ` Eric Blake
@ 2016-10-13 6:39 ` Markus Armbruster
0 siblings, 0 replies; 3+ messages in thread
From: Markus Armbruster @ 2016-10-13 6:39 UTC (permalink / raw)
To: Eric Blake; +Cc: Vladimir Sementsov-Ogievskiy, qemu-devel
Eric Blake <eblake@redhat.com> writes:
> On 10/12/2016 10:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>> HI all!
>>
>> My questions is: what are general recommendations in Qemu for return
>> code, if we have Error **errp?
>> What should I prefer: errp, duplicated by int return code, or void
>> functions with errp?
>
> Markus has already had several threads commenting on this very topic in
> the past. A lot of code uses void return, but some newer code is using
A recent one:
Message-ID: <87a8ekfenp.fsf@dusky.pond.sub.org>
http://lists.gnu.org/archive/html/qemu-devel/2016-10/msg00435.html
> the past. A lot of code uses void return, but some newer code is using
> an int return for simplifying the call-sites (and glib prefers the int
> rather than void return, as well). Markus was playing with a Coccinelle
> script to see how painful a bulk-conversion of the code base would be,
> but it is probably stalled behind more pressing work at the moment.
Correct.
>> void + errp seems good, just to not duplicate things. But it has a
>> disadvantage of necessity of "local_err" and "error_propagate" in caller
>> function, if its behaviour depends on callee function success...
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-10-13 6:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-12 15:47 [Qemu-devel] error reporting in functions Vladimir Sementsov-Ogievskiy
2016-10-12 20:55 ` Eric Blake
2016-10-13 6:39 ` Markus Armbruster
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.