你用一段时间结束你的exception信息吗？
我已经看到有和没有句点的两个exception消息。 我可以想一些为什么两个都可以的好理由。
- 没有点会给你自由添加期限或离开它，如果你想。 如果邮件进入某种标题栏或某物，可能会有用。
- 用一个点，你总是会知道你有一个“完整的句子”，看起来更完整。
你推荐哪一个？
也可能是本地化资源string中的问题。 很明显，你不能在所有事情之后放置一段时间（在button和菜单项上的文本之后的周期看上去很奇怪）。 但是，你是否应该把所有的时间都放在一致的地方，然后在有用的地方添加它？ 或者你宁愿放一个看起来合适的时期？ 例如，在所有的资源string和exception消息是句子之后，而不是在那些单词之后。 但是，那么短句怎么样呢？ 比如“创build一个新文件”。 也许可以省略那些被认为是行动的string…（只是想在我在这里打字…
不是世界上最重要的事情，我知道。 但是像这样的小事在一段时间之后往往会让我烦恼。 我喜欢一致性，并知道为什么我要做我所做的事情。 问题是我不确定哪一个要去：p
是的，我通常把exception信息当作完整的句子，以句点结尾。
但是，exception中的消息仅供开发人员使用 ，而不是最终用户 。 很可能，相同的底层exception应该为最终用户产生两个不同的消息，这取决于调用exception抛出方法的上下文。
你真的应该显示更less的技术，用户更友好的信息给用户。
问：你是否用一段时间来结束你的exception信息？
从“创build和引发exception”部分的MSDN上的例外 †的 最佳实践 † ：
- 使用语法正确的错误消息， 包括结束标点符号 。 例外的描述string中的每个句子都应该以句点结尾。 例如，“日志表溢出”将是一个适当的描述string。
关于通过应用程序用户界面对用户的可能反馈，问题包括：
…也可能是本地化资源string中的问题。
上面引用的MSDN文章还指出：
- 在每个例外中包含一个本地化的描述字符 用户看到的错误消息是从抛出exception的描述string派生而来的，而不是从exception类派生的。
另外，在“注释”部分的开始处的Exception.Message属性 † ：
错误消息的目标是处理exception的开发人员。 Message属性的文本应该完整地描述错误，并且在可能的情况下还应该解释如何纠正错误。 顶级的exception处理程序可能会将消息显示给最终用户，所以您应该确保它在语法上是正确的，并且消息的每个句子都以句点结尾。 不要使用问号或感叹号。 如果您的应用程序使用本地化的exception消息，则应确保它们被准确翻译。
† .NET Framework 4.6和4.5
框架中的exception消息以点结尾; 我也倾向于这样做。
无论如何，select一种风格，并试图坚持…
我总是在我的例外描述中使用句点。 简单的事实是，句子是正确的标点符号更容易阅读，更专业，这是重要的感知质量 – 你不觉得吗？
比较它：
我总是在我的例外情况描述中使用句点，简单的事实是句子被正确地打断是更容易阅读和更专业的看，这是重要的感知质量你不觉得
exception消息构成了应用程序开发者接口的一部分。 接口通常是为了帮助用户执行一些特定的任务而devise的。 在出现exception的情况下，所提供的接口应devise为传达有关在应用程序中发生的错误的信息。
当你决定抛出一个exception，写一个像
throw new ArgumentException("The string must contain at least one character."); 那么你已经做了一些关于界面的决定，包括：
- exceptiontypes
- 缺乏本地化的exception消息（使用硬编码的string通常意味着这一点）
- 这个例外不是任何其他条件的结果（没有内部例外）
请记住，开发人员接口的存在是为了为开发人员和用户界面提供服务的用户，前者的要求与后者有很大的不同，因此对于其他用户来说，好的一方可能对另一方不利，用户界面，因为它不应该是最终用户可见的。
在大多数情况下，使用期限不是一个重大决定，但是考虑到已经提出的包括框架一致性和本地化在内的一些要点，您应该考虑是否存在（或缺less存在）对接口是有益的还是有害的。
我知道这篇文章有点罗嗦，可能有一点astronauty ，但我希望这对你有帮助。
使用你最好的判断。 我有时也使用感叹号。 🙂
