Committed in r1139195.
- Julian
On Thu, 2011-06-23, Hyrum K Wright wrote:
> On Thu, Jun 23, 2011 at 1:17 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> > Greg Stein wrote:
> >> Thanks for taking the time to do thus. Only recently did I realize that I
> >> named the function incorrectly when I came up with it. In PoCore, I called
> >> it pc_error_trace(), for the same reasons you suggested here.
> >
> > OK, I'll do it.
> >
> > Does anyone want me to leave "svn_error_return" as an alias for the time
> > being, to be removed before 1.7.0, to avoid gratuitous failures with
> > developers' local mods and when applying patches over the next few days?
> > I'll happily do so if anyone says "yes" (it's very little extra work),
> > but if no-one says "yes" then I won't.
>
> Don't bother leaving the alias. Folks will have to fix it sooner or
> later, might as well have them do it sooner.
>
> >> > There are 695 uses of svn_error_return.
> >> >
> >> > 681 of them are "return svn_error_return(...);".
> >> >
> >> > The other 14 are "some_err = svn_error_return(...);".
> >> >
> >> > So if we're going to change the vast majority of these in any way, what
> >> > do folks feel about replacing them with
> >> >
> >> > SVN_ERR_RETURN(...)
> >>
> >> No.
> >>
> >> SVN_ERR() is conditional. Code typically occurs afterwards, and is executed
> >> in the non-exceptional case. You're talking about creating a normally-used
> >> macro that will hide this control flow change.
> >
> > OK, good to hear your input.
>
> Same. I knew there was a reason we didn't use this form when we were
> designing this macro, but I just couldn't put my finger on it.
>
> -Hyrum
Received on 2011-06-24 10:10:33 CEST