您是否以句点结束异常消息?[关闭]


72

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

  • 如果您愿意,没有点可以让您自由添加或不添加句点。如果消息以某种标题栏或类似内容显示,则可能很有用。
  • 带有一个点,您将始终知道您有一个“完整的句子”,而且看起来更完整了。

您推荐哪一个?

在本地化资源字符串中也可能是一个问题。显然,您不能在所有内容后面加上句号(在按钮和菜单项等上的文字之后会显得很奇怪)。但是,您是否应该将所有期间都排除在外以保持一致,并在以后有用时将其添加?还是您宁愿放置一段看起来合适的时期?例如,在所有资源字符串和异常消息之后都是句子,但不在单词之后。但是,那么短的句子又如何呢?例如,例如“创建新文件”。也许也可以省去一些被认为是动作的字符串...(只是在我在这里输入内容时思考...)

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

Answers:


58

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

但是,异常中的消息是针对开发人员的,而不是针对最终用户的。完全相同的基础异常可能会导致最终用户收到两条不同的消息,具体取决于调用异常抛出方法的上下文。

您确实应该向用户显示技术性较低,用户友好性更高的消息。


56

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

最佳实践例外在部分MSDN上的“创建和引发异常”:

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

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

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

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

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

另外,在“备注”部分开头的Exception.Message属性中:

错误消息针对正在处理异常的开发人员。Message属性的文本应完整描述错误,并在可能的情况下还应说明如何更正错误。顶级异常处理程序可能会将消息显示给最终用户,因此您应确保其语法正确,并且消息的每个句子都以句点结尾。请勿使用问号或感叹号。如果您的应用程序使用本地化的异常消息,则应确保正确翻译它们。


.NET Framework 4.6和4.5


9

框架中的异常消息以点结尾。因此,我倾向于这样做。
无论如何,选择一种风格并尝试坚持下去...


6

我总是在例外说明中使用句点。一个简单的事实是,正确标点的句子更易于阅读和看起来更专业,这对于感知质量很重要-您认为吗?

比较一下:

我总是在例外说明中使用句点,简单的事实是正确标点的句子更易于阅读,而且看起来更专业,这对您认为的质量至关重要


3
我认为不向最终用户显示异常消息会提高感知质量。
安德斯·桑德维格

2
@Anders-取决于您的显示方式。如果捕获并正确呈现给用户,则异常看起来可能非常专业。没抓到?好吧,那只是一个崩溃!
戴夫·马克尔

4

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

当您决定引发异常并像这样写一行时

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

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

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

请记住,存在开发人员界面来为开发人员服务,而用户界面则是为用户服务,前者的需求与后者的需求有很大的不同,因此对一个人有利的可能对另一个不利,因此应在异常消息中加一个句点不关心用户界面,因为它对最终用户不可见。

在大多数情况下,时间段的使用不是主要的决定,但是您应该通过考虑已经提出的问题(包括框架的一致性和本地化),来考虑时间段的存在(或缺乏)是否对接口有利还是有害。

我知道这篇文章有点罗word,也许有点天文,但我希望它对您有所帮助。


0

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


当我看到开发人员这样做时,这真的让我很烦。感叹号仅应用于表示情感,除非您有一个非常活泼,可爱,友好的应用程序,否则我不会使用它们。
现场直播
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.