Re: [Qemu-devel] [RFC PATCH v1 0/5] Add error_abort and associated cleanups

[Eric Blake]

On 12/03/2013 01:33 PM, Igor Mammedov wrote:

>>> Also, is it worth adding asserts and/or compiler annotations to require
>>> that the Error **err argument of functions be non-NULL, to ensure that
>>> callers are always passing either a valid destination or one of the
>>> special addresses?  But doing so would probably require adding a special
>>> address for error_ignore for callers that intend to discard an error in
>>> cases where the return type of the function lets them know to proceed
>>> with a fallback implementation (that is, cases where ignoring an error
>>> makes sense).
>>
>> Right now, we use NULL as "ignore errors" argument.
>>
>> NULL gives us a chance to express "caller must not ignore errors" via
>> some non-null annotation that gets fed to a static analyzer.
>>
>> I doubt that would be possible with a special error_ignore object.
>>
>> Anyway, this series is about "abort on error".  Let's keep "ignore
>> errors" issues separate.
> I'm sorry for hijacking thread, but that actually an issue that started an
> original discussion.
> Where void returning QOM API functions are used with NULL, without any chance
> to detect that error happened. So abusing NULL errp in this functions
> might lead to hard to find runtime errors.
> I think Eric's suggestion was to enforce passing non NULL errp and let caller
> to deal with error gracefully so that above mentioned misuse was impossible.
> Why is ignoring errors from "void foo(...)" like API considered acceptable?

Okay, so it sounds like consensus is that using NULL as the means to
ignore errors is okay when there is an alternative way to detect error,
but that for any function that returns void, adding an assert(errp)
would be appropriate because the caller cannot safely ignore the
failure.  It's not worth inventing an error_ignore special address, but
for functions that have no way to report errors except via errp, then it
IS worth enforcing that the caller is either prepared to handle the
error or has passed &error_abort (or any other special addresses we add
later).

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

signature.asc
Description: OpenPGP digital signature