Re: [PATCH v4 2/3] module: add Error arguments to module_load_one and module_load_qom_one

[Claudio Fontana <cfontana@suse.de>]

On 9/22/22 11:31, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2022 at 11:20:07AM +0200, Claudio Fontana wrote:
>> On 9/22/22 10:28, Daniel P. Berrangé wrote:
>>>
>>>> Another interface that does: return -1 for error, 0 for module not found
>>>> (no error), and 1 for loaded.
>>>
>>> IMHO this pattern is generally easier to understand when looking at
>>> the callers, as the fatal error scenario is always clear.
>>>
>>> That said I would suggest neither approach as the public facing
>>> API. Rather stop trying to overload 3 states onto an error reporting
>>> pattern that inherantly wants to be 2 states. Instead just have
>>> distinct methods
>>>
>>>   bool module_load_one(const char *prefix, const char *name, Error *errp)
>>>   bool module_try_load_one(const char *prefix, const char *name, Error *errp)
>>
>>
>> Here we are murking again the normal behavior and the error path.
>>
>> What is the meaning of try? It's not as though we would error out inside the function module_load_one,
>> it's the _caller_ that needs to decide how to treat a return value of found/not found, and the exception (Error).
> 
> I suggested "try" as in the  g_malloc vs g_try_malloc API naming pattern,
> where the latter ignores the OOM error condition.
> 
> So in this case 'try' means try to load the module, but don't fail if
> the module is missing on disk.

I understand what you mean, but this is wrong in this case.

We _do not fail_ in module_load_one, whether an error is present or not, whether a module is found or not.