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

Resolution: only print specific error message when present

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-12-07 02:45:28 CET

In http://www.contactor.se/~dast/svn/archive-2003-11/0504.shtml Erik
submitted a patch to print only the specific error message when
present. This comes from my input to issue #897 back in June
Phillip tentatively objected to the patch, saying:

> If repetition is such a crime, how about

> svn: File not found
> svn: 'foo'

> Suppose we are returning an SVN_ERR_FOO error, at present the
> general error error text allows us to identify the error as a FOO
> error. If the FOO error is generated in several places there will no
> longer be a single message that identifies a FOO error. Can you
> explain why this is clearly an improvement?

I think it is much more important to display brief, elegant,
non-redundant error messages than it is to be able to reverse-map an
error message to an error code. Error codes are for programs, not for
people. Given only the specific error message, one should still
usually be able to reverse-map to a location in the source where the
error is generated. (And, of course, enable-maintainer-mode builds
will display that information along with the error.)

I am strongly in favor of the patch. With no other comments, it's
hard to determine the sense of the community on this issue. So, speak
up unless your apathy about this point is true and thorough. (Back in
June, Branko agreed with the idea, but that's still only 3 to 1.
Branden Robinson noted that a GUI might have use for both a general
and specific error message, but we won't be reducing the amount of
information available to the GUI, just the amount of information
printed by the command-line client.)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 7 02:45:59 2003

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.