On Wed, Jul 10, 2013 at 12:40 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Bert Huijben wrote on Tue, Jul 09, 2013 at 22:32:00 +0200:
>> > -----Original Message-----
>> > From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
>> > Bert Huijben wrote on Tue, Jul 09, 2013 at 20:11:57 +0200:
>> > > How is this going to help?
>> >
>> > I already told you how: it is going to help because API users can't do
>> > anything with the value 120171 that they presently receive. The
>> > outermost error must be defined by APR or by Subversion. 120171 is
>> > neither.
>>
>> *Why* ?
>>
>> There is no rule that apr_err must be set to something that is defined by
>> APR or Subversion.
>>
>
> 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?
For client apr_err is just error code. Client uses
svn_err_best_message() to get error message and there're some known
APR, Subversion *and* serf error codes.
So please revert back old behavior with propagating serf error codes
to the caller. It's very important for clients to have distinguished
error codes for different cases. Client could use to provide special
suggestions how to fix this error or something. Error code 'some error
from serf' does not help in such cases.
Original code in ra_serf constructed all svn_error_t with serf error
codes with custom error message, so user should never get 'APR doesn't
understand this error code' message. It should be fixed if we
construct svn_error_t with serf error code without custom error
message.
--
Ivan Zhakov
Received on 2013-07-15 18:36:10 CEST