Re: [Qemu-devel] [PATCH] qom: abort on error in property setter if caller passed errp == NULL

[Markus Armbruster]

Igor Mammedov <address@hidden> writes:

> On Thu, 28 Nov 2013 15:10:50 +1000
> Peter Crosthwaite <address@hidden> wrote:
>
>> Hi,
>> 
>> On Thu, Nov 28, 2013 at 11:24 AM, Igor Mammedov <address@hidden> wrote:
>> > in case if caller setting property doesn't care about error and
>> > passes in NULL as errp argument but error occurs in property setter,
>> > it is silently discarded leaving object in undefined state.
>> >
>> > As result it leads to hard to find bugs, so if caller doesn't
>> > care about error it must be sure that property exists and
>> > accepts provided value, otherwise it's better to abort early
>> > since error case couldn't be handled gracefully and find
>> > invalid usecase early.
>> >
>> > In addition multitude of property setters will be always
>> > guarantied to have error object present and won't be required
>> > to handle this condition individually.
>> >
>> 
>> So there seems to be contention between different APIs and use cases
>> on what to do in the NULL case. Personally, I'm of the opinion that
>> NULL should be a silent don't care policy. But you are right in that
> If caller doesn't care about setting property was successful, it perhaps
> shouldn't call property setter at all or pass a dummy errp for special
> case if he really doesn't care about error (I can't really come up with
> use case though).
>
> Otherwise there is chance that property setter fails and object won't be
> in state it's supposed to be. If developer passes NULL for errp, that
> should mean that he is sure call will succeed, if it fails/aborts
> developer will find about error much earlier than when in field deployment
> starts misbehaving in unpredicable way.

When you're sure the call can't fail, you really, really want an
assertion failure when it does.

There's a use for "I don't want an error object, thank you": when you
can detect failure in another way, say return value, and aren't
interested in details, and the notational overhead that comes with it.

This case is distinct from "I know this can't fail".

[...]