On Mon, 2002-08-05 at 17:48, Dave Cridland wrote:
> 1) Verbosity: Extra verbosity is one token, at minimum:
Too much, in my opinion. Error messages should be short and sweet.
On IRIX, if you ls a bad file, you see:
UX:ls: ERROR: Cannot access blah: No such file or directory
The "UX" and "ERROR" are "only" a few extra letters. But except in some
specific circumstance I don't even know about, it's extra crud to wade
through before I can find out what's wrong.
> 2) Other programs and systems *do* do this. Not all, it's true. But I
> imagine you recognise "SIGSEGV" in a program quite readily, and any http
> application you ever see give you a 404 is also an example of this to an
> extent.
I never see "SIGSEGV" when a program crashes; I see "Segmentation
fault." And I can hardly do a web search for "404" and get much of use.
> Perhaps you meant that it is incorrect practice to cover
> "uncommon cases". I'm simply not sure exactly what this means in this
> context.
In this case, the common case suffers a needless increase in verbosity,
while the uncommon case gets a little extra help looking things up by
web search. (And it's not clear to me that this extra help is generally
needed.)
If you think really hard about the uncommon case, this might seem like a
good tradeoff. How hard is it to scan over the ugly-looking Subversion
constant, after all? But if you make decisions like this routinely, the
resulting system will be cumbersome to use.
I've heard this principle (the one I am applying) called "the fairness
principle," though that doesn't seem to be a standard term. You don't
put code in the core path of a performance-critical program to handle a
rare corner case which could be handled (perhaps less efficiently) in
another way. A good C++ exception-handling system should not add even
one instruction to the case where an exception does not occur, even to
save a thousand instructions in the case where an exception does occur.
> a) My example was possibly poor, a more useful example might be someone
> natively working in, say, Polish, seeking help through the international
> community, which largely does not understand Polish.
I suppose... but the value of Polish-language information is so much
higher than the value of foreign-language information that I'm not sure
that it's useful to make it easier to find help in English or Italian.
> 6) I, personally, disagree with the assertion that this "obfuscates" the
> error. To me, errors which are accompanied by a human-recognisable code
> are clearer, as well as being more communicable. This appears to be true
> of many people on this list, hence the occasional use of the term
> "sigsegv", rather than segmentation fault, or access violation, and
> "404" rather than "File or resource not found".
Subversion developers may certainly find it easier to communicate in
terms of "SVN_ERR_NOT_WC" (or whatever) instead of a "Not a working
copy" error. But I suspect most users, particularly developers, will
mostly find such a code obstructive.
If I lose this argument, I would at least suggest downcasing the
constant name and putting it in parentheses before displaying it to the
user. Yes, the downcasing could make it a little harder to search the
Subversion code base for the constant, but if it's in all uppercase then
the user's attention is called to the less useful information at the
expense of the more useful information.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 00:47:29 2002