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