Daniel Rall wrote:
> On Fri, 04 Aug 2006, Molle Bestefich wrote:
>
>
>>C. Michael Pilato wrote:
>>
>>>Since much of the command-line parsing stuffs was abstracted into
>>>libsvn_subr from its original location in 'svn' (the command-line client),
>>>there is a particular annoyance that shows up in certain circumstances.
>>
>>There's a whole slew of annoyances regarding Subversion's error messages.
>>A whole lot of the time, the error messages printed by Subversion just
>>SUCKS.
>
>
> Molle, please report these instances to the dev list as bugs
> (i.e. with reproduction recipe).
Nonono. Please don't. Hundreds of issues about this kind of thing aren't
really going to help.
As I've stated many times in the past, the majority of the problem as I see
it with Subversion error messages can be summarized in one macro name:
SVN_ERR()
Rather than taking the time to document our APIs as throwing particular
error codes, and teaching those things to intercept errors from lower levels
and return them wrapped with more-focused error codes, we have a situation
today where for the majority of the API function calls made by the likes of
the command-line client, any one of hundreds of error codes could come back.
At that level, there is *no way* the client code can possible translate
each of those things into meaningful user output.
We're better -- *much better* -- about this in the FS library, where many of
the APIs are documented to raise particular error codes to reveal particular
states, and where callers can bank on those being the most commonly raised
error conditions. But I mean, that a user of the command-line client would
*ever* see an error code that has the term "MKACTIVITY" or a DAV activity ID
or something about invalid anchoring ... that's just developer laziness.
There's nothing negative that I can see about about error code
proliferation. The more, the merrier.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Aug 4 22:00:29 2006