Bert Huijben wrote:
> Julian Foad wrote:
>>> In most cases it is safer to check for an error somewhere in the chain as
>>> what is returned as the root cause (the most inner error) is not really the
>>> error that caused the error when error chains are composed. Perhaps we
>>> should
>>> also extend the documentation to explain this bit.
>>
>> You added a comment about this in the implementation in r1553266:
>>
>> svn_error_t *
>> svn_error_root_cause(svn_error_t *err)
>> {
>> while (err)
>> {
>> /* I don't think we can change the behavior here, but the additional
>> error chain doesn't define the root cause. Perhaps we should rev
>> this function. */
>> if (err->child /*&& err->child->apr_err != SVN_ERR_COMPOSED_ERROR*/)
>> err = err->child;
>> else
>> break;
>> }
>>
>> return err;
>> }
>>
>> I also noticed that you made svn_error_compose_create insert the
>> SVN_ERR_COMPOSED_ERROR marker, but not svn_error_compose. I think
>> of those two functions as synonymous with slightly different calling
>> conventions, but now they differ in this respect, for no apparent reason.
>> Can you comment on that?
>
> I didn't add that...
> (perhaps I might have tweaked that)
Oh, sorry -- Daniel Shahaf added the separator in r1409804, and you gave it a
specific error code in r1553266.
> I see a lot of PROs and CONs on that behavior change...
>
> Yes it allows filtering for this specific case, but we have a lot of code
> that just walks the chain... And svn_error_t is a struct&chain that is also
> used directly by api users.
Daniel, can you comment on that?
- Julian
