> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: woensdag 9 april 2014 14:09
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1585921 -
> /subversion/trunk/subversion/include/svn_error.h
>
> 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?
I didn't add that...
(perhaps I might have tweaked that)
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.
Bert
>
> - Julian
Received on 2014-04-09 14:16:25 CEST