[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Misleading error messages.

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2006-08-18 11:47:47 CEST

Erik Huelsmann wrote:
> Molle Bestefich wrote:
> > If that translates to "you think Subversion error messages are fine
> > the way they are", then you're totally out of sync with the real
> > world. And real users. No offence :-).
> If you think that, you didn't read the rest of the message: I think
> we're totally unclear in our error messages.

Ok. My apologies.

> But I think there's a different reason than most people seem to think:
> I think we provide errors out-of-context and we should be providing
> the context instead of making our errors more generic:

I agree that loss of information (from making errors more generic, say) is bad.
Not sure how your SVN_ERR_W proposal would work.

> What would it help you if subversion would tell you
> "Update failed: protocol error"?

I see your point about generalization. Not much, if any. It's
lacking crucial details, and it's telling me nothing about what svn
was trying to do (other than "update via a protocol").
 - What protocol, HTTP or WebDAV (wrapped in HTTP)?
 - During which phase of the update?
 - Was there a server-side failure, and if so, which?
 - If not, was there a client-side failure, and if so, which?
 - (Extremely over-the-top helpful: Any clues, eg. common reasons for
this failure?)

I happen to think that the most efficient way to make useful error
messages is to bubble the message up and add useful information at
each layer.

svn: update failed
  client: protocol error
    webdav: unexpected response to initial MKCOL
      neon: HTTP authentication failure


svn: update failed
  client: protocol error
    webdav: unexpected response to initial MKCOL
      server: mod_svn: Repository not found, check Apache configuration

... or whatever, something like that :-).

All the intermediate information is useful to a beginner because it
tells you something about what was in general happening in the
Subversion server and client at the moment. It would probably be less
useful to an expert, who has a better chance of just guessing it. The
final, inner-most error message would be useful to both expert and
beginners alike.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 18 11:48:19 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.