[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

The SVN_ERR_COMPOSED_ERROR marker [was: svn commit: r1585921 - /subversion/trunk/subversion/include/svn_error.h]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 9 Apr 2014 14:27:32 +0100 (BST)

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
Received on 2014-04-09 15:28:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.