Bert Huijben wrote on Mon, Aug 12, 2013 at 14:16:40 +0200: > > > > -----Original Message----- > > From: Ivan Zhakov [mailto:i...@visualsvn.com] > > Sent: maandag 15 juli 2013 18:35 > > To: Subversion Development; Daniel Shahaf > > Cc: Bert Huijben > > Subject: Re: Semantics of svn_error_t->apr_err > > > > On Wed, Jul 10, 2013 at 12:40 AM, Daniel Shahaf <d...@daniel.shahaf.name> > > wrote: > > > Bert Huijben wrote on Tue, Jul 09, 2013 at 22:32:00 +0200: > > >> > -----Original Message----- > > >> > From: Daniel Shahaf [mailto:d...@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. > > Ping?
Thanks for this. It was on my radar to get back to this thread, but I had it mentally classed as "things to look at before 1.9 is branched" so didn't treat it as urgent. In the meantime I reverted the change on trunk. Sorry for the delay.
