On Mon, 2002-08-05 at 19:30, Greg Hudson wrote:
> On Mon, 2002-08-05 at 14:07, Dave Cridland wrote:
> > As mentioned before, Google is often the best source of online help for
> > what errors *really* mean.
>
> > Since the rest of the string can be internationlised, I for one would
> > really like a "This is error code 'SVNERROR_TOOMANYERRORCODES'" string
> > somewhere, giving me a suitable searchable token.
>
> I don't think it's worth the verbosity.
1) Verbosity: Extra verbosity is one token, at minimum:
svn: SVNERROR_BADEXAMPLE: This example is probably no good.
> Other programs don't do this,
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.
> and it seems to optimize for the uncommon case
3) This is not intended to be an optimization, but an addition.
"optimize for the uncommon case" implies "at the expense of the common
case". Perhaps you meant that it is incorrect practice to cover
"uncommon cases". I'm simply not sure exactly what this means in this
context.
> (where the error message
> is non-obvious,
4) If only this were uncommon by itself. But *all* error messages will
be non-obvious to some people, and *some* error messages may well be
non-obvious to almost everyone, in a sad parody of PT Barnum.
> and the user would think to use google, and google would
> actually find something useful given the error code, and google wouldn't
> find something useful given the error message)
5)
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.
b) The code can be searched on Google, communicated via IRC, or sent to
this very mailing list, where only a minority of people speak Polish. (I
know we have a couple of Polish speakers on here, hence my choice as an
example language.)
c) The same code can be used for more extensive local,
internationalized, help, as Mark Benedetto King suggests - I wouldn't
want to remove the "error text" entirely, though.
> at the expense of
> obfuscating the common case.
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".
Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 5 23:44:48 2002