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
or
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