On Tue, Jul 9, 2013 at 4:40 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Bert Huijben wrote on Tue, Jul 09, 2013 at 22:32:00 +0200:
>...
>> There is no rule that apr_err must be set to something that is defined by
>> APR or Subversion.
Correct.
> I've nothing new to say. I think every svn_error_t we return from our
> APIs should have an APR_ERR member which is either:
>
> - equal to SVN_WARNING;
> or
> - in some SVN_ERR_CATEGORY_*_START, in the sense defined by
> SVN_ERROR_IN_CATEGORY();
> or
> - outside the [APR_OS_START_USERERR, APR_OS_START_USERERR+500000]
> range, *and* valid according to APR's concept of validity for
> apr_status_t values outside that range (which in particular means:
> be non-zero).
>
> Can someone please weigh in on this issue?
The apr_status_t type was designed/intended to hold multiple ranges of
errors. It can hold errors from apr, apr-util, httpd, svn, serf, and
third-party/unknown libraries.
The *problem* is that a central registry of who gets what range was
never codified. There was a lot of discussion way back when, but no
consensus. We added svn's range into the apr_errno.h header, and were
willing to add other libraries/products. Dunno whether the current APR
folks still feel that way.
And because it never got codified, Subversion just "used up" all the
space. Or maybe APR defined it based on svn's use. I don't recall the
exact ordering.
Note that Apache HTTPD defines errors in there, at USERERR+1000
(weirdly, it only defines a single error; it does say that it reserves
1000 error codes).
When we went to define some serf errors, we recognized that Subversion
(by design or accident) begins its errors at USERERR+5000. So serf
decided to take USERERR+100 to stay away from svn and httpd. It
doesn't make it explicit in the header, but there is an implicit
assumption of a 100 slot reservation.
apr_status_t is intended to hold all of these errors, so we shouldn't
attempt to remap them. Handle the ones that you recognize, and
propagate everything else (maybe somebody up the call chain knows how
to handle it). And that caller may be outside of our APIs. We publish
an apr_status_t to them for review.
Cheers,
-g
Received on 2013-07-10 03:00:25 CEST