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

Re: svn commit: r1585921 - /subversion/trunk/subversion/include/svn_error.h

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 9 Apr 2014 13:09:24 +0100 (BST)

Bert Huijben wrote:
>> URL: http://svn.apache.org/r1585921
>> Log:
>> * subversion/include/svn_error.h
>>   (svn_error_root_cause): Document that the returned error should not
>>     be cleared, just like in svn_error_find_cause.
>
> As all the errors in a chain are in the same pool, clearing the root cause or
> the complete chain is really the same thing
>
> But it is probably safer to document it this way... as it is certainly wrong to
> clear both chains.
>
>
> 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?

- Julian
Received on 2014-04-09 14:10:04 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.