Re: Misleading error messages.

On Fri, 04 Aug 2006, C. Michael Pilato 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.
>
> 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.

I expect errors to be caught and turned into something meaningful as
close to where they're generated as possible (e.g. FS errors which
need sensitive info stripped out), not way out at the client layer --
outside the client library -- where there are a large number of
possible error codes to handle.

Error messages which we control that have descriptions which mention
MKCOL or MKACTIVITY or whatever can likely be improved directly.

I don't see why we wouldn't want to hear about either of these cases.