Greg Stein wrote on Wed, May 11, 2011 at 15:35:19 -0400:
> On May 11, 2011 2:05 PM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
> >
> > On 05/11/2011 12:00 PM, Daniel Shahaf wrote:
> >...
> > >
> > > When wrapping apr_status_t's returned by serf, shouldn't we decorate
> > > them in some way so that code that interprets them knows to look them up
> > > in serf.h:SERF_ERROR_* rather than in svn_error_codes.h ?
> > >
> > > Not sure, perhaps a wrapper err->apr_err link that signals to
> > > subr/error.c to call into serf to stringify the child link...?
> >
> > I'm actually not sure that Serf even provides a stringification function
> at
> > all.
>
> Good idea. I can fix that.
>
> > svn_error_wrap_apr() will use 'status' as the err->apr_err value, but
> > will call APR's stringification function which, I would expect, would just
> > drop some generic string in place (since the Serf error code range is
> > outside of APR's own). Of course, there's no guarantee that Subversion's
> > and Serf's error code ranges won't overlap,
>
> You have a guarantee :-)
Since svn_error_t.apr_err may contain either an svn error code or a serf
error code, do we care to have an API that tells people which one it is?
Use case: API consumers who don't log err->message and want to
call svn_strerror(err->apr_err).
Received on 2011-05-11 22:12:20 CEST