Question

在编写抛出我询问here的异常的代码时，我走到了我的消息的末尾，并在标点符号处停了下来。我意识到几乎所有我抛出的异常消息都可能有！某处。

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!!!!!");

编写异常消息时你会采取什么样的语气？在浏览日志时，您是否发现任何特定类型的消息实际上比其他消息更有帮助？

Answer 1

事实上。包括调试时可能需要的所有信息，但不多于此。

我唯一一次在异常消息中包含感叹号，如果它表明某些事情确实发生了奇怪的事情。大多数错误不是非常奇怪，只是环境不正确，用户错误或简单的编程错误的产物。

Answer 2

我尝试反映我编码的框架的语气，语法和标点符号样式。你永远不知道其中一条消息何时可能真正在客户或用户面前出现，所以我保持一切专业，非评判性和具体到足以进行故障排除 - 没有具体到放弃任何安全问题。代码。

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

Answer 3

系统消息中的对话音使得软件看起来不专业且不马虎。感叹号，侮辱和俚语在抛光异常消息中确实没有位置。

此外，我倾向于在Java中使用不同的样式来处理运行时异常和检查异常，因为运行时异常是针对造成错误的程序员的。由于运行时异常可能会显示给最终用户，我仍然“保持清洁”，但它们可能会更加简洁和神秘。检查的异常消息应该更有帮助，因为如果您描述它可能是用户可以解决问题（例如，找不到文件，磁盘已满，没有到主机的路由等）。

在缺少信息例外的特定字段的情况下，有一件事是有用的：违规数据：

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

Answer 4

承担责任，即使确实是用户的错，也是我见过的最佳选择。

“我找不到你想要的文件，你会检查我是否正确使用它？”或者“出了点问题。不知道怎么回事，但我能解决的唯一办法是停止。请重新启动我。”

Answer 5

简洁，详细和少量冗余信息（即ArgumentNullException显然涉及null）。

但这是我读过的最好的一段时间，首先回答this。

Answer 6

我不会过多地使用感叹号。他们表达得太多，想想“驱动器中没有磁盘！”这一事实。可以读作“没有磁盘驱动你疯狂的用户”。 ;）

我认为抛出包含国际化文本的异常是明智的。您永远不知道谁将使用您的代码，捕获您的异常并向用户显示文本。那就是：

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

我还建议在投掷时包装底层异常（如果有的话）。它真的有助于调试。

不要认为用户不会看到运行时异常。如果您要登录文件追加器，一些好奇的用户可能只是打开日志并查看您的脏秘密。

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.

最难学的一点是，您的用户对代码内部的兴趣远远低于完成工作所需的内容。让他们尽可能轻松地完成工作。他们的工作，你为你的软件增加了巨大的价值。

Answer 8

我倾向于将异常消息自己处理成异常。例如。 file_not_found应该说“找不到文件”。只有在用户无法弄清楚的情况下才应包含特定数据;在这种情况下，用户知道文件名，所以我不添加该数据。格式化可以通过必要的输出信息来完成，所以我尽量使它们尽可能地重新格式化。

Answer 9

礼貌，简洁，简洁，具体。通常，在消息中包含状态值是有帮助的。

你用什么样的异常消息？

9 个答案: