在编写引发我询问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!!!!!");
您在编写异常消息时采用什么语气？浏览日志时，您是否发现某种特定风格的消息实际上比另一种更有帮助？
【问题讨论】：
标签： c# .net exception logging throw
系统消息中的对话音使软件看起来不专业且草率。感叹号、侮辱和俚语在优美的异常消息中并没有真正的位置。
此外，我倾向于在 Java 中对运行时异常和检查异常使用不同的样式，因为运行时异常是针对犯错误的程序员的。由于运行时异常可能会显示给最终用户，因此我仍然“保持干净”，但它们可以更简洁和神秘一些。检查的异常消息应该更有帮助，因为如果您描述它，用户可能可以解决问题（例如，找不到文件、磁盘已满、没有到主机的路由等）。
在信息异常没有特定字段的情况下，有一点很有帮助，那就是违规数据：
throw new IndexOutOfBoundsException("offset < 0: " + off);
【讨论】：
只是事实。包括调试时可能需要的所有信息，但仅此而已。
我唯一会在异常消息中包含感叹号的情况是它表明发生了非常非常奇怪的事情。大多数错误并不很奇怪，只是不正确的环境、用户错误或简单的编程错误的产物。
【讨论】：
我尝试反映我正在编码的框架的语气、语法和标点样式。您永远不知道其中一条消息何时会真正出现在客户或用户面前，因此我保持一切专业、非判断性和足够具体的内容以进行故障排除 - 没有具体到泄露任何安全问题代码。
我避免在所有字符串（UI 和异常）中使用感叹号，就像瘟疫一样，除了（偶尔）在我的单元测试中。
【讨论】：
承担责任，即使确实是用户的错，也是我见过的最佳选择。
类似于“我找不到你想要的文件，你能检查一下我是否有正确的文件？”这样的事情。或“出了点问题。不知道是什么，但我能解决的唯一方法就是停下来。请重新启动我。”
【讨论】：
简洁、详细且冗余信息少（即 ArgumentNullException 显然涉及 null）。
但这是我最近读过的最好的，首先回答this。
【讨论】：
我不会过多地使用感叹号。他们表达的太多了，想想“驱动器中没有磁盘！”的事实。可以读作“疯狂的用户在驱动器中没有磁盘”。 ;)
我认为抛出包含国际化文本的异常是明智的。你永远不知道谁会使用你的代码，捕捉你的异常并向用户显示文本。 那就是：
throw new MagicalException(getText("magical.exception.text"));
我还建议在抛出它时包装底层异常（如果有的话）。它确实有助于调试。
不要以为用户不会看到运行时异常。如果您正在登录到文件附加程序，一些好奇的用户可能会打开日志并查看您的 dirty 秘密。
【讨论】：
我发现提供的最有用的信息：
最重要的是：
例子：
commit.c 第 42 行中的错误 203（超时）： 无法将用户“Linus”的工资数据保存到“10.10.1.21”的数据库中 1500 毫秒后。验证数据库地址和登录凭据。
最难学习的一课是，您的用户对代码内部的兴趣远不如他们对完成工作的兴趣。让他们尽可能轻松地完成工作他们的工作，你为你的软件增加了巨大的价值。
【讨论】：
我倾向于将我的异常消息放入异常本身。例如。 file_not_found 应该说“找不到文件”。仅当用户无法弄清楚时才应包含特定数据；在这种情况下，用户知道文件名，所以我不添加该数据。如有必要，可以通过任何输出信息来完成格式化，所以我尽量让它们对重新格式化尽可能友好。
【讨论】：
礼貌、简洁、简单、具体。通常，在消息中包含状态值很有帮助。
【讨论】：