您对异常消息使用什么样式？
在编写引发异常的代码时，我询问了 这里，我到达了消息的末尾，并在标点符号处停了下来。 我意识到我抛出的几乎每个异常消息都可能有一个！ 某处。
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!!!!!");
您在撰写异常消息时采用什么语气？ 在查看日志时，您是否发现某种特定类型的消息实际上比其他类型更有帮助？
In writing the code that throws the exception I asked about here, I came to the end of my message, and paused at the punctuation. I realized that nearly every exception message I've ever thrown probably has a ! somewhere.
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!!!!!");
What tone do you take when writing exception messages? When going through logs, do you find any certain style of message actually helps more than another?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我尝试反映我正在编码的框架的语气、语法和标点符号风格。 您永远不知道其中一条消息何时会真正出现在客户或用户面前，因此我将所有内容保持专业、非评判性且足够具体，以便进行故障排除 - 而又不会过于具体以至于泄露信息中的任何安全问题。代码。
我避免在所有字符串（UI 和异常）中使用感叹号，就像瘟疫一样，除了（偶尔）在我的单元测试中。
I try to mirror the tone, grammar and punctuation style of the framework against which I'm coding. You never know when one of these messages might actually make it out in front of a client or user, so I keep everything professional, non-judgmental and specific enough for troubleshooting -- without being so specific as to give away any security issues in the code.
I avoid exclamation marks in all strings (UI and exception) like the plague, except (ocasionally) in my unit tests.
就事论事吧。 包含调试时可能需要的所有信息，但仅此而已。
我唯一会在异常消息中包含感叹号的情况是，如果它表明发生了非常非常奇怪的事情。 大多数错误实际上并不奇怪，只是不正确的环境、用户错误或简单的编程错误的产物。
Just be matter of fact. Include all the information you're likely to need when debugging, but no more than that.
The only time I'd include an exclamation mark in an exception message is if it indicates that something really, really bizarre has happened. Most errors aren't really bizarre, just the product of an incorrect environment, user error, or a simple programming mistake.
承担责任，即使确实是用户的错，也是我见过的最好的选择。
类似于“我找不到您想要的文件，您可以检查一下我是否正确吗？” 或“出了点问题。不知道是什么，但解决问题的唯一方法就是停止。请重新启动我。”
Taking responsibility, even when it really was the user's fault, is the best option I've seen.
Things along the lines of "I can't find the file you wanted, would you check to see I have it correctly?" or "Something went wrong. Dunno what, but the only way I can get fixed is by stopping. Please restart me."
简洁、详细且冗余信息很少（即ArgumentNullException 显然涉及null）。
但这是我一段时间以来读过的最好的文章，首先回答这个。
Concise, detailed and little redundant information (i.e. ArgumentNullException obviously involved a null).
But here's the best i've read for a while, first answer to this.
我不会过多使用感叹号。 他们表达得太多了，想想“驱动器中没有磁盘！”这一事实。 可以理解为“驱动器中没有磁盘，你这个疯狂的用户。” ;)
我认为抛出包含国际化文本的异常是明智的。 您永远不知道谁会使用您的代码、捕获您的异常并向用户显示文本。
所以那就是：
我还建议在抛出异常时包装底层异常（如果有的话）。 它确实有助于调试。
不要认为用户不会看到运行时异常。 如果您正在记录到文件附加程序，一些好奇的用户可能会打开日志并窥视您的肮脏秘密。
I wouldn't use exclamation marks too much. They express too much, think about the fact that "No disk in drive!" can be read as "No disk in drive you crazy user." ;)
I think that it's wise to throw exceptions that contain internationalized text. You never know who will use your code, catch your exception and display the text to the user.
So that would be:
I also recommend wrapping the underlying exception (if you have one) when throwing it. It really helps debugging.
Don't think that runtime exceptions won't be seen by the user. If you are logging to a file appender some curious user might just open the log and peek into your dirty secrets.
我发现最有帮助的消息提供：
最重要的是：
示例：
最难学到的教训之一是，用户对代码内部结构的兴趣远不如他们对完成工作的兴趣。让他们尽可能轻松地完成工作，您已经为您的软件增加了巨大的价值。
I find the most helpful messages provide:
And most important:
Example:
One of the hardest lessons to learn is that your users are far less interested in the internals of your code than they are in getting their jobs done. Make it as easy as possible for them to do their jobs, and you've added tremendous value to your software.
我倾向于将异常消息融入到异常本身中。 例如，file_not_found 应该显示“文件未找到”。 仅当用户无法弄清楚时才应包含特定数据； 在这种情况下，用户知道文件名，所以我不添加该数据。 如有必要，可以通过任何输出信息来完成格式化，因此我尝试使它们尽可能友好地重新格式化。
I tend to work my exception messages into the exception themselves. E.g. a file_not_found should say "file not found". Specific data should only be included if the user can't figure it out; in this case, the user knows the filename, so I don't add that data. Formatting can be done by whatever outputs the information if necessary, so I try to make them as friendly to reformatting as possible.
礼貌、简洁、简单、具体。 通常，在消息中包含状态值会很有帮助。
Polite, terse, simple, specific. Often, including state values in message is helpful.
系统消息中的对话语气使该软件看起来不专业且草率。 感叹号、侮辱和俚语在精美的异常消息中实际上没有一席之地。
另外，我倾向于在 Java 中对运行时异常和检查异常使用不同的样式，因为运行时异常是针对犯错误的程序员的。 由于运行时异常可能会显示给最终用户，我仍然“保持干净”，但它们可以更加简洁和神秘。 检查的异常消息应该更有帮助，因为如果您描述问题，用户可能可以修复问题（例如，未找到文件、磁盘已满、没有到主机的路由等）。
在没有信息例外的特定字段的情况下，有问题的数据是有用的：
A conversational tone in system messages makes the software look unprofessional and sloppy. Exclamation points, insults, and slang don't really have a place in polished exception messages.
Also, I tend to use different styles in Java for runtime exceptions and checked exceptions, since runtime exceptions are addressed to the programmer that made the mistake. Since runtime exceptions might be displayed to end users, I still "keep it clean," but they can be a little more terse and cryptic. Checked exception messages should be more helpful, since it may be that the user can fix the problem if you describe it (e.g., file not found, disk full, no route to host, etc.).
One thing that is helpful, in the absence of a specific field on the exception for the information, is the offending data: