On Sun, 2003-11-23 at 19:39, Branko Èibej wrote:
> kfogel@collab.net wrote:
> >Sometimes it's better, like with checksum mismatch error messages that
> >compare actual vs expected checksum -- you want the two checksums to
> >line up vertically. For example this code from reps-strings.c:
Note that the current error message only lines up the checksums with a
fixed-width font.
> This is one of the bits of error handling code we discussed.
>
> I argued against newlines in favour of using svn_error_t chaining to
> break out the separate lines, because that's much friendlier to GUI clients.
>
> Greg argued against both newlines and svn_error_t chaining, on the
> grounds that the lines belong to the same error message, and therefore
> should not be wrapped in a lower-level error..
I think the issue of multi-line error messages is a tough one, and we
should avoid it by sticking to single-line error messages for now.
Branko also wrote:
> >+ * Provide specific error messages only when there is information
> >+ to add to the general error message found in
> >+ subversion/include/svn_error_codes.h
> If we enforce this, then we must allow parameter placeholders in those
> messages. Otherwise people can't both use svn_error_createf and obey
> this guideline.
There must be some misunderstanding here.
My belief is: if you're returning something like SVN_ERR_XML_MALFORMED,
and you have nothing to add to the generic error message ("XML data was
not well-formed"), you should provide NULL as the error message, and the
error handler will use the generic message. On the other hand, let's
say we want to show what file and line the malformed XML data was on; in
this case, you should provide a message that stands on its own, like:
XML data was not well-formed in file '%s', line '%d'
and the error handler should display just this message, and not the
generic one.
Is it bad that we are replicating the default message here? I don't
think so. For one thing, if we vary the wording differently, it doesn't
actually hurt. (Phillip complained that the user would have no
immediate way to identify that two error messages share the same error
code, but who cares? Error codes are for programs, not for humans, and
if you're grepping for an error message, you're actually going to have
an easier time if it's more unique, not less unique.) For another,
adding parameter placeholders to the generic error messages would be
over-engineering.
Am I clear?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 24 02:13:42 2003