You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@elego.de> on 2013/05/28 09:42:17 UTC

svn_error_create(SERF_ERROR_FOO, NULL, NULL);

Just got a report of a problem with 1.8.0-rc2:

    svn: E120104: ra_serf: An error occurred during decompression

The error code is unrecognised; that's because it's not an SVN_ERR_* code:

    % ./tools/dev/which-error.py E120104
    00120104  *** UNKNOWN ERROR CODE ***
    % ./tools/dev/which-error.py E120000
    00120000  APR_OS_START_USERERR
    % grep -B 1 -w 4 -h /usr/local/serf-1.2.0/serf-1/include/*
    #define SERF_ERROR_DECOMPRESSION_FAILED (APR_OS_START_USERERR + \
                                                 SERF_ERROR_RANGE + 4)

The problem is that svn_ra_serf__wrap_err() passes a serf error code to
svn_error_create().  That's a problem, as API consumers won't be able to
make sense of the code: it's not in any SVN_ERROR_*_CATEGORY_START
category, svn_strerror() and svn_error_symbolic_name() will reject it,
etc.

I am not sure what to do instead.  Maybe we define an
SVN_ERROR_SERF_ERROR error number and map all serf error numbers to it.
Maybe we define a few more of those for specific common serf errors, too
(like we do for sqlite).  Maybe we just reserve [APR_OS_START_USERERR
+ 100, APR_OS_START_USERERR + 199] to serf error codes.

Thoughts?

Re: svn_error_create(SERF_ERROR_FOO, NULL, NULL);

Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <da...@elego.de> writes:

> Just got a report of a problem with 1.8.0-rc2:
>
>     svn: E120104: ra_serf: An error occurred during decompression
>
> The error code is unrecognised; that's because it's not an SVN_ERR_* code:
>
>     % ./tools/dev/which-error.py E120104
>     00120104  *** UNKNOWN ERROR CODE ***
>     % ./tools/dev/which-error.py E120000
>     00120000  APR_OS_START_USERERR
>     % grep -B 1 -w 4 -h /usr/local/serf-1.2.0/serf-1/include/*
>     #define SERF_ERROR_DECOMPRESSION_FAILED (APR_OS_START_USERERR + \
>                                                  SERF_ERROR_RANGE + 4)
>
> The problem is that svn_ra_serf__wrap_err() passes a serf error code to
> svn_error_create().  That's a problem, as API consumers won't be able to
> make sense of the code: it's not in any SVN_ERROR_*_CATEGORY_START
> category, svn_strerror() and svn_error_symbolic_name() will reject it,
> etc.
>
> I am not sure what to do instead.  Maybe we define an
> SVN_ERROR_SERF_ERROR error number and map all serf error numbers to it.
> Maybe we define a few more of those for specific common serf errors, too
> (like we do for sqlite).  Maybe we just reserve [APR_OS_START_USERERR
> + 100, APR_OS_START_USERERR + 199] to serf error codes.
>
> Thoughts?

See http://subversion.tigris.org/issues/show_bug.cgi?id=4368 for another
example.  Trunk gives:

   svn: warning: W120190: Error running context: An error occurred during authentication

with 1.7/neon the error was:

  svn: E175002: Server sent unexpected return value (401 Authorization Required) in response to LOCK request for '/obj/repo/A/f'

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download