logo标签列表

你在异常信息结尾处加句号吗？

c#exceptioncoding-stylemessage
97

我看到过有带句号和不带句号的异常消息。我可以想到一些原因，为什么两者都有其优点：

  • 不带句号可以让你自由地添加或省略句号，如果要将消息放在标题栏或其他地方可能有用。
  • 带句号则始终知道你有一个“完整的句子”，看起来更加完整。

你推荐哪一个呢？

在本地化资源字符串中也可能成为问题。显然，你不能在所有内容后面都加上句号（为按钮和菜单项等文本加上句号会很奇怪）。但是你是否应该保持所有资源字符串的一致性并在需要时添加句号呢？还是你宁愿在适当的位置添加句号呢？例如，对于所有被认为是句子的资源字符串和异常消息，以及不是单词的字符串后面都应该加上句号。但是对于非常短的句子如，“创建新文件”这样的句子，可能可以不加句号...（我边打字边思考...）

虽然这不是世界上最重要的事情，但是这类小细节经过一段时间之后会让我感到不舒服。我喜欢一致性，并且要知道为什么自己做某些事情。问题是，我不确定该选择哪个:p

6个回答
75
从MSDN上的异常最佳实践†中，关于“创建和引发异常”部分的内容如下：
使用语法正确的错误消息，包括结束标点符号。异常说明字符串中的每个句子都应以句号结尾。例如，“日志表已溢出。”是一个适当的说明字符串。
关于通过应用程序用户界面向用户提供反馈的可能性，问题包括：
...也可能是本地化资源字符串中的问题。
上述引用的MSDN文章还指出：
在每个异常中包含本地化的说明字符串。用户看到的错误消息来自抛出的异常的说明字符串，而不是异常类。
此外，在"备注"章节的开头，来自Exception.Message Property†：

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

† .NET Framework 4.6和4.5

69

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

然而，异常消息是为开发人员而设计的，而不是最终用户。很可能同一基础异常应该针对不同的上下文在最终用户中产生两个不同的消息。

你真的应该向用户显示更少的技术性、更加友好的消息。

10

框架中的异常消息以点号结尾；出于这个原因，我倾向于做同样的事情。
无论如何，选择一种风格并努力坚持...

9

我总是在我的异常描述中使用句号。简单的事实是，适当标点的句子更易于阅读并且看起来更专业，这对于感知质量非常重要 - 你不觉得吗？

与之相比：

我总是在我的异常描述中使用句号。简单的事实是，适当标点的句子更易于阅读并且看起来更专业，这对于感知质量非常重要 - 你不觉得吗？

3
我认为不向终端用户显示异常信息可以提高知觉质量。 - Anders Sandvig
2
@Anders -- 这取决于你如何展示它。如果异常被正确捕获并呈现给用户，那么异常看起来可以非常专业。未被捕获？那就是崩溃！ - Dave Markle
5
异常消息是应用程序开发者接口的一部分。接口通常旨在帮助用户执行某些特定任务。对于异常情况，提供的接口应该设计为传达有关应用程序中发生的错误的信息。
当您决定抛出异常并编写类似以下代码行的内容时：
throw new ArgumentException("The string must contain at least one character.");

如果你已经决定了界面的一些内容，包括：

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

请记住，开发人员界面存在于为开发人员服务，用户界面存在于为用户服务，前者具有迥异的要求，所以对于一个好的界面可能对另一个来说不是很好，因此在异常消息中加上句号不应该影响用户界面，因为它对最终用户不可见。

在大多数情况下，使用句号并不是一个重大的决定，但你应该考虑其存在（或不存在）是否有益于界面，包括框架一致性和本地化等已经提出的问题。

我知道这篇文章有点啰嗦，可能有点 astronauty，但我希望对你有所帮助。

0

请根据您的判断使用最佳方式。我有时也会使用感叹号。 :-)

2
当我看到开发者这样做时，真的很恼火。感叹号只应用于表示情感，除非你有一个相当傻笑、可爱、友好的应用程序，否则不应使用它们。 - live-love
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接