On 8/4/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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.
Nor can we at all times decide what a user will perceive as helpfull:
some may even require the MKCOL part in the error message. That's why
I have advocated in the past to make better use of yet another macro:
SVN_ERR_W()
When inserted at strategic points in our code, we can explain to the
user what we were doing when the given error occured. I'm convinced
most SVN_ERR()s should stay as they are, but there are some points
(calls to svn_wc_adm_crawler or other large operations) where
SVN_ERR_W could really help clarify what's going on when the error
occurred.
Hiding detail isn't necessarily what needs to be done to clarify our
output (IMO).
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 17 20:47:02 2006