Re: [RFC] error: auto propagated local_err

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

19.09.2019 17:44, Eric Blake wrote:
> On 9/19/19 9:30 AM, Vladimir Sementsov-Ogievskiy wrote:
> 
>>>
>>> To the same topic, of minimization: should we always call MAKE_ERRP_SAFE at function top, or only
>>> in block, where it is needed (assume, we dereference it only inside some "if" or "while"?
>>> Kevin, is something bad in propagation, when it not related to error_abort?
>>>
>>>
>>
>> Or, even, we may use MAKE_ERRP_SAFE on every function, which have Error **errp argument, even if we neither
>> dereference it nor append hints? Is it what you propose by "SINGLE paradigm"? It's of course simpler to script,
>> to check in checkpatch and to maintain.
> 
> Yes. The simpler we make the rules, and the less boilerplate it entails,
> the more likely that we can:
> 
> a) avoid exceptions and corner cases that cost review time
> b) automate the conversion into complying with the rule
> c) codify those rules in syntax check to ensure they are followed
> post-conversion
> 
> ALWAYS using MAKE_ERRP_SAFE() on entry to any function that has an Error
> **errp parameter is dirt-simple to explain.  It has no performance
> penalty if the user passed in a normal error or error_abort (the cost of
> an 'if' hidden in the macro is probably negligible compared to
> everything else we do), and has no semantic penalty if the user passed
> in NULL or error_fatal (we now get the behavior we want with less
> boilerplate).
> 
> Having to think 'does this method require me to use MAKE_ERRP_SAFE, or
> can I omit it?' does not provide the same simplicity.
> 

Interesting: it's another story, but with this macro used in each errp-function we can collect
the whole call-stack of the error int Error object, and report it.
It may be not good for end-user, but very useful for testing.

Or is it bad idea? Anyway, I often have the problem: I have some error reported, and need to
understand where was it from.. git grep helps, but backtrace would be a lot better.

-- 
Best regards,
Vladimir