你用一段时间结束你的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 ,但我希望这对你有帮助。

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