81

我已经看到了带句点和不带句点的异常消息。我可以想到为什么两者都可以很好的一些原因。

  • 如果您愿意,任何点都不会让您自由添加句点或将其省略。如果消息出现在某种标题栏或其他内容中,可能会很有用。
  • 使用点,您将始终知道您有一个“完整的句子”,并且看起来更完整。

你推荐哪一个?

也可能是本地化资源字符串中的问题。显然,您不能在所有内容之后加上句点(在按钮和菜单项等的文本后加上句点会显得很奇怪)。但是,您是否应该将句点从所有内容中剔除以保持一致并稍后在有用的地方添加它?还是您宁愿在合适的地方设置一个时期?例如,在所有资源字符串和异常消息都是句子之后,而不是在单词之后。但是,非常短的句子怎么样?例如,“创建一个新文件”。可能也可以省略被视为操作的字符串的句点......(只是在我在这里打字时思考......)

我知道,这不是世界上最重要的事情,但像这样的小事情往往会在一段时间后困扰我。我喜欢一致性,并且知道我为什么要做我所做的事情。问题是,我不确定该选择哪一个:p

4

6 回答 6

65

是的,我通常将异常消息视为完整的句子,并以句点结尾。

但是,异常中的消息是针对开发人员的,而不是针对最终用户的。很可能同一个底层异常应该为最终用户产生两条不同的消息,这取决于调用异常抛出方法的上下文。

你真的应该向用户展示更少技术性、更友好的信息。

于 2009-07-16T11:01:22.217 回答
64

问:您是否以句点结束您的异常消息?

来自MSDN 上“创建和引发异常”部分的“异常最佳实践” † :

  • 使用语法正确的错误信息,包括结尾标点符号。异常描述字符串中的每个句子都应以句点结尾。例如,“日志表已溢出。” 将是一个适当的描述字符串。

关于通过应用程序用户界面对用户的可能反馈,问题包括:

...也可能是本地化资源字符串中的问题。

上面引用的 MSDN 文章还指出:

  • 在每个异常中包含本地化描述字符串。用户看到的错误消息是从引发的异常的描述字符串派生的,而不是从异常类派生的。

此外,来自“备注”部分开头的Exception.Message 属性† :

错误消息针对正在处理异常的开发人员。Message 属性的文本应该完整地描述错误,并且如果可能,还应该解释如何更正错误。顶级异常处理程序可能会向最终用户显示消息,因此您应该确保它在语法上是正确的,并且消息的每个句子都以句点结尾。不要使用问号或感叹号。如果您的应用程序使用本地化的异常消息,您应该确保它们被准确翻译。


.NET 框架 4.6 和 4.5

于 2015-12-07T14:34:51.813 回答
9

框架中的异常消息是点终止的;出于这个原因,我倾向于做同样的事情。
无论如何,选择一种风格并尝试坚持下去......

于 2009-07-16T11:03:20.667 回答
7

我总是在我的异常描述中使用句点。一个简单的事实是,正确标点的句子更容易阅读,看起来更专业,这对于感知质量很重要——你不觉得吗?

将其与以下内容进行比较:

我总是在我的异常描述中使用句点,一个简单的事实是,正确标点的句子更容易阅读,看起来更专业,这对于感知质量很重要,你不认为

于 2009-07-16T11:03:16.270 回答
4

异常消息构成了应用程序开发人员界面的一部分。界面的设计通常旨在帮助用户执行某些特定任务。在异常情况下,所提供的接口应设计为传达有关应用程序中发生的错误的信息。

当你决定抛出一个异常并写一行像

throw new ArgumentException("The string must contain at least one character.");

那么您已经对界面做出了许多决定,包括:

  • 异常类型
  • 缺少本地化异常消息(使用硬编码字符串通常意味着这一点)
  • 此异常不是任何其他条件的结果(没有内部异常)

请记住,开发者界面是为开发者服务的,而用户界面是为用户服务的,前者的要求与后者有很大不同,所以对一个人有利的可能对另一个人不利,所以异常消息中的句号应该不关心用户界面,因为它不应该对最终用户可见。

在大多数情况下,句点的使用不是一个重大决定,但您应该考虑已经提出的要点,包括框架一致性和本地化,来考虑它的存在(或缺乏)对界面是有利还是有害。

我知道这篇文章有点罗嗦,可能有点航天,但我希望它对你有所帮助。

于 2009-07-16T12:11:25.787 回答
0

用你最好的判断。我有时也会使用感叹号。:-)

于 2009-07-16T11:28:38.120 回答