Bert Huijben wrote on Tue, Jul 09, 2013 at 20:02:48 +0200:
>
>
> > -----Original Message-----
> > From: 'Daniel Shahaf' [mailto:d.s_at_daniel.shahaf.name]
> > Sent: dinsdag 9 juli 2013 18:39
> > To: dev_at_subversion.apache.org
> > Cc: commits_at_subversion.apache.org
> > Subject: Re: svn commit: r1501049 - in /subversion/trunk/subversion:
> > include/svn_error_codes.h libsvn_ra_serf/util_error.c
> >
> > Daniel Shahaf wrote on Tue, Jul 09, 2013 at 16:20:56 +0000:
> > > I accept that some API users may depend on
> > SVN_ERR_RA_SERF_WRAPPED_ERROR. Do
> > > you think it is a problem to assign that new meaning to it in 1.8.x? I
> reused
> > > it for the same reasons you re-used an existing error code in r1498851,
> if
> > you
> > > think a new error code is needed on trunk I'm happy to add one.
> >
> > Looking at your comment:
> >
> > The reason for the -1 is the re-use of a specific error
> code
> > that is automatically unwrapped in some ra_serf code,
> to avoid
> > handling codes like APR_EOF as non fatal)
> >
> > Weere does ra_serf *unwrap* SVN_ERR_RA_SERF_WRAPPED_ERROR?
> >
> > % grep 'SVN_ERR.*SERF' subversion/*rf/*.[hc]
> > subversion/libsvn_ra_serf/options.c:
> > SVN_ERR_ASSERT(SVN_RA_SERF__HAVE_HTTPV2_SUPPORT(session));
> > subversion/libsvn_ra_serf/options.c:
> > SVN_ERR_ASSERT(!SVN_RA_SERF__HAVE_HTTPV2_SUPPORT(session));
> > subversion/libsvn_ra_serf/serf.c: SVN_ERR_ASSERT(!
> > SVN_RA_SERF__HAVE_HTTPV2_SUPPORT(session));
> > subversion/libsvn_ra_serf/update.c: return
> > svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> > subversion/libsvn_ra_serf/util.c: return
> > svn_error_create(SVN_ERR_RA_SERF_SSL_CERT_UNTRUSTED, NULL, NULL);
> > subversion/libsvn_ra_serf/util.c: err =
> > svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> > subversion/libsvn_ra_serf/util.c: err =
> > svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> > subversion/libsvn_ra_serf/util.c: err =
> > svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> > subversion/libsvn_ra_serf/util_error.c: err =
> > svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> > % grep 'SVN_ERR.*SERF' subversion/*{ra,client} | wc -l
>
> Slightly more context:
> I see 5 usages:
> 1:
> /* Some errors would be handled by serf; make sure they really make
> the update fail by wrapping it in a different error. */
> if (!SERF_BUCKET_READ_ERROR(err->apr_err))
> return svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
>
> 2:
> if (err && !SERF_BUCKET_READ_ERROR(err->apr_err))
> err = svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
>
> 3:
> if (err && !SERF_BUCKET_READ_ERROR(err->apr_err))
> err = svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
>
> 4:
> if (err && !SERF_BUCKET_READ_ERROR(err->apr_err))
> err = svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
>
> 5:
> if (serf_err_msg)
> {
> err = svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> err_msg = serf_err_msg;
> }
>
> Which one is not specifically mapping specific error types?
>
I don't understand the question. All 5 uses you paste above use
SVN_ERR_RA_SERF_WRAPPED_ERROR in exactly the same manner: as a wrapper
error code that is propagated directly to libsvn_ra's caller.
What problem do you see in usage 5?
> Note that all of these cases handle specific APR error codes as specific for
> SERF.
> (except the last one of course)
>
> Bert
>
Received on 2013-07-09 22:00:30 CEST