On Wed, Jul 10, 2013 at 02:52:21AM +0400, Ivan Zhakov wrote:
> On Wed, Jul 10, 2013 at 1:51 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> >> -----Original Message-----
> >> From: Branko Čibej [mailto:brane_at_wandisco.com]
> >> Sent: dinsdag 9 juli 2013 23:12
> >> To: dev_at_subversion.apache.org
> >> Subject: Re: svn commit: r1501371 -
> >> /subversion/trunk/subversion/libsvn_ra_serf/util_error.c
> >>
> >> On 09.07.2013 23:00, Bert Huijben wrote:
> >> > I would welcome a patch to svn_strerror that improves the default
> >> > error for serf specific error codes,
> >>
> >> That would effectively make our make implementation details of
> >> libsvn_ra_serf part of the public API. That's a non-strarter IMO.
> >>
> >> > or a patch that translates all serf error codes to something within a
> >> > subversion error range.
> >>
> >> If we go down that road, we may as well make Serf part of the Subversion
> >> project. Which I don't believe is going to happen.
> >>
> >> By all means wrap the error messages inside libsvn_ra_serf; I wouldn't
> >> object to extracting the Serf error message and adding a "caused-by:
> >> serf error NNNN" in the same error chain.
> >
> > Which requires tools to start message scraping?
> >
> > My Chinese error parser is not so good, and perhaps somebody changes the .po file with the next patch release?
> >
> >
> > TortoiseSVN, VisualSVN, AnkhSVN and probably most other GUI clients prefer error values over texts.
> > (I don't know about our JavaHL users, but I know more than a few SharpSvn users that have checks for specific error codes in their products)
> >
> I completely agree with Bert that having error is very important for
> GUI clients. The source of error code doesn't matter actually. It just
> some stable identifier of particular error and reason. GUI client may
> suggest solution based on this error code. Or ignore it in some cases.
As already mentioned, the original Serf error code remains, it is simply
placed in the second place in the error chain, and the front place is
given to an error that describes the second place's apr_status_t value
as a Serf one.
API users that use svn_error_find_cause() won't even know the
difference. (And given that they are looking for a Serf-generated error
code, looking at the bottom rather than top of the chain is probably a
good idea --- but I admit I'm talking with 20/20 hindsight here.)
Received on 2013-07-10 02:18:18 CEST