kfogel@collab.net wrote:
>"Erik Huelsmann" <e.huelsmann@gmx.net> writes:
>
>
>>The patch below tries to describe the conventions I try to adhere to when
>>changing error messages for issue 897; it can also be found at
>>http://encorps.dnsalias.com/svn-public/patches/HACKING.patch.
>>
>>
>
>Thanks for writing this up -- much needed!
>
>Comments below. Mostly I agree with your suggested conventions, except
>for one:
>
>
>
>>+ * Don't include newline characters in error messages.
>>
>>
>
>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:
>
>
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..
> if (! svn_md5_digests_match (checksum, rep->checksum))
> return svn_error_createf
> (SVN_ERR_FS_CORRUPT, NULL,
> "svn_fs__rep_contents: checksum mismatch on rep \"%s\":\n"
> " expected: %s\n"
> " actual: %s\n", rep_key,
> svn_md5_digest_to_cstring (rep->checksum, trail->pool),
> svn_md5_digest_to_cstring (checksum, trail->pool));
>
>So maybe the guideline should be "Try not to" instead of "Don't" ?
>
>
I still think I'm right, and I agree with Erik and Greg that newlines
have no place in the error messages. We should _not_ force clients to
parse the error messages or reformat the lines. If that means we need an
extra mechanism in addition to chaining to construct multilined
messages, then so be it.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 24 01:38:10 2003