You know, I have to admit I wonder if a client (in particular, our
command-line client) even needs its own error system similar to the
Subversion libraries. The motivation is not clear...
Yes, for the *libraries*, we need specific error codes because in many
cases we have to promise exactly what errors are returned under what
circumstances. The caller sometimes catches them and handles them
specially.
But the client itself has no callers. Can't it just always return an
svn_error_t based on the underlying error code (which is either an
svn-specific code, or an apr code), and use the customizable string to
describe the error to the user? And on the rare occasions when it
needs to throw an error out of whole cloth (i.e., not based on an
underlying library or apr error), it can just use APR_EGENERAL, or
something like that. The string would say everything that needs to be
said, since this is only for human consumption anyway. Why does a
client need to return specific error codes at all?
Below I answer your questions as best I can, but my overriding concern
is given above.
Daniel Stenberg <daniel@haxx.se> writes:
> 1. Several places in the client code, use library error codes when error
> messages are generated. I don't think this is a good idea, as the error
> code could be used to see in which domain the problem is, and thus I
> think client code should only use its own error codes when generating
> errors.
There should be a client error wrapping the underlying library error.
See svn_error.h for details about error wrapping.
> 2. The errors currently named SVN_ERR_CL_* in the svn_error_codes.h should
> (if you agree) be used by errors generated by libsvn_client.
Just checking: do you mean that SVN_ERR_CL_ should be the prefix used
by libsvn_client, and the command-line client would use some other
prefix? In your client_errors.h below, you currently use SVN_ERR_CL_.
(This file lives in subversion/clients/cmdline/, right?)
> 3. Regarding naming, is the error codes to be considered private? I mean
> should thet have two underscores or only one?
I think two. These are #defines, not symbols noticed by the linker,
but they still will be existing in a namespace where Subversion
library #defines are allowed as well.
> This is the first draft of 'client_errors.h'. This would need to get more
> codes added and some codes should possibly be removed from svn_error_codes.h
>
> #ifdef __cplusplus
> extern "C" {
> #endif /* __cplusplus */
>
> #define SVN_ERROR_START \
> typedef enum svn_client_errno_t { \
> SVN_CL__WARNING = SVN_ERR_LAST + 1,
> #define SVN_ERRDEF(n, s) n,
> #define SVN_ERROR_END SVN_CL__ERR_LAST } svn_client_errno_t;
>
> #define SVN_ERROR_ENUM_DEFINED
I'm a little confused. Isn't this going to redefine the
SVN_ERROR_START macro? Some files will have to #include both
svn_error_codes.h and client_errors.h, will this be a problem?
(Instinct tells me I'm missing something obvious here, but I can't put
my finger on what.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006