I agree with Dave, basically.
The error code number is very confusing to the user; but an error code
string (e.g., "SVN_ERR_WC_CORRUPT" or whatever) is somewhat less
confusing, because at least it looks like words. Happily, it's also
far more useful for developers than the numeric code, and is not
affected by language translation. Also, we sometimes tweak the error
strings, but we still want to be able to unambiguously recognize the
error.
If we do our best to display it somewhere unobtrusive when printing an
error, then we get the best of both worlds, or at least not the worst
of any world.
Mind you, I'm not about to go and implement this tomorrow. But if
someone sent in a patch, that'd be great, IMHO...
-K
Dave Cridland <dave@cridland.net> writes:
> 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
---------------------------------------------------------------------
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:09:44 2002