你使用什么样式来处理异常信息？

Question

在编写我之前在这里提到的异常代码时，我来到了消息的结尾，并停顿在标点符号处。我意识到我所抛出的几乎每个异常消息都可能有一个！。

throw new InvalidOperationException("I'm not configured correctly!");
throw new ArgumentNullException("You passed a null!");
throw new StupidUserException("You can't divide by 0!  What the hell were you THINKING???  DUMMY!!!!!");

在编写异常信息时，您采用什么语气？在查看日志时，您是否发现某些消息样式比其他样式更有帮助？

- Chris Marasti-Georg

Answer 1

系统消息中使用对话式语气会让软件看起来不够专业、粗糙。感叹号、侮辱和俚语在优雅的异常消息中并没有什么位置。

此外，我倾向于在Java中为运行时异常和已检查异常使用不同的样式，因为运行时异常是针对犯错误的程序员的。由于运行时异常可能会显示给最终用户，所以我仍然保持简洁明了，但它们可以更加简洁和神秘。已检查异常消息应该更有帮助性，因为如果您描述问题（例如未找到文件、磁盘已满、无法连接到主机等），用户可能能够修复问题。

在没有特定字段用于信息的情况下，一个有用的东西是有关违规数据的信息：

throw new IndexOutOfBoundsException("offset < 0: " + off);

- erickson

Answer 2

我尝试模仿我所编码的框架的语气、语法和标点风格。您永远不知道这些消息何时可能真正呈现给客户或用户，因此我保持专业、不带评判性，并具有足够的特定性以进行故障排除，但又不会过于详细以至于泄露代码中的任何安全问题。

我在所有字符串（UI 和异常）中避免使用感叹号，除了（偶尔）在我的单元测试中。

- John Rudy

Answer 3

保持简洁明了，包含所有调试所需信息，但不要过多冗余。

只有在异常信息表明发生了非常奇怪的事情时，我才会在其中包含感叹号。大多数错误并不是真正的奇怪，只是由于错误的环境、用户错误或简单的编程错误导致的。

- Jon Skeet

Answer 4

即使用户出现了错误，承担责任仍然是我见过的最好的选择。

例如：“我找不到你想要的文件，请确认我是否正确？”或者“出现了一些问题，我不知道是什么，但唯一能解决的方法就是停止。请重新启动我。”

- warren

---

这些错误消息可以显示给用户，但不是我会包含在异常对象中的内容。 - Jon Skeet

像问题中的那些消息肯定是为用户而设计的，不是吗？ - warren

我真的希望不是这样。用户怎么可能“传递了一个空值”呢？异常消息确实是为开发人员和技术支持而设计的。它们应该是支持日志的一部分，但默认情况下不应该显示给用户，我个人认为。（它们可以成为“详细信息…”结果的一部分。） - Jon Skeet

对Jon的评论点赞 - 抛出异常的代码不应该为用户格式化消息，而是捕获异常的代码尽可能地为用户提供帮助。 - Chris Marasti-Georg

@John：严厉的爱，这是他们学习的唯一方式。 ;) - Chris Marasti-Georg

Answer 5

简明、详细且不冗余的信息（即ArgumentNullException显然涉及null）。

但是这是我读过的最好的东西之一，是对这个问题的第一个回答。

- dove

Answer 6

我不建议过多使用感叹号。它们表达得太过强烈，想想“驱动器中没有磁盘！”可以被理解为“驱动器中没有磁盘，你这个疯狂的用户！” ;)

我认为最好抛出包含国际化文本的异常。因为你永远不知道谁会使用你的代码、捕获你的异常并将文本显示给用户。

throw new MagicalException(getText("magical.exception.text"));

我建议在抛出异常时包装底层异常（如果有的话）。这真的有助于调试。

不要认为运行时异常不会被用户看到。如果您正在记录到文件附加器，一些好奇的用户可能会打开日志并窥探您的“肮脏”秘密。

- Bogdan

Answer 7

我发现最有用的消息应该提供以下内容：

• 一种一致的格式，使得理解所传达的内容变得容易。
• 时间戳，以便您了解程序的动态。
• 一个简短的错误摘要。如果您提供技术支持，请添加一个错误代码以便快速识别。
• 对出错原因的解释，区分无效用户输入和编码错误。
• 详细信息，包括涉及的代码行或值。

最重要的是：

• 他们告诉用户如何解决问题。

例如：

Error 203 (Timeout) in commit.c line 42:
Unable to save salary data for user 'Linus' to database at '10.10.1.21'
after 1500ms.  Verify database address and login credentials.

其中最难学习的一课是，您的用户远不如他们在完成工作时感兴趣于您的代码内部。尽可能地帮助他们完成工作，这将为您的软件增加巨大价值。

- Adam Liss

Answer 8

我倾向于将异常消息嵌入到异常本身中。例如，文件未找到应该说“文件未找到”。仅在用户无法解决问题时才应包含特定数据；在这种情况下，用户知道文件名，因此我不会添加该数据。如果必要，输出信息的格式可以由任何东西完成，因此我尽量使它们易于重新格式化。

- coppro

Answer 9

礼貌、简洁、简单、具体。通常情况下，将状态值包含在消息中会更有帮助。

- dongilmore