是否应该报告异常的消息文本？

Question

考虑一些可以抛出检查异常的代码（类型为Exception的例外）。当然，你的代码catch是个例外。你不只是吞下异常，你的代码通过你的用户界面以某种方式报告给用户。在一个日志文件中，或者使用GUI弹出窗口。

您向用户报告的文本是否应该包含异常的消息文本。也就是说，文中提供的Throwable.getMessage()或Throwable.getLocalizedMessage()？

我认为不是，但似乎很多人不同意我。那么我有什么错误？我的论点如下。

• 该消息是在抛出异常时创建的。因此，它最多只能提供非常低的信息，这可能不适合向用户报告。
• 在哲学上，使用该消息对我来说似乎违反了例外的全部观点，即将检测和启动错误处理（throw部分）与完成处理和报告（catch部分）分开。使用该消息意味着该消息必须适合于报告，这将报告的责任转移到仅应该对检测和启动负责的位置。也就是说，我认为Throwable设计的getMessage()部分是一个错误。
• 该消息未本地化。尽管它的名称是getLocalizedMessage()，但它并不是很好，因为您可能不知道要使用的语言环境，除非您的例外情况是catch（是由英语系统管理员阅读的系统日志报告，还是以弹出式格式用于GUI的法国用户的窗口？）。
• 我听说Java 7的IOException的异常层次结构有了很大的改进，使您能够处理不同种类的I/O错误，不同的catch子句，使得getMessage()文本不那么重要。这意味着即使Java设计人员对getMessage()也有些不舒服。

---

我不问是否报告堆栈跟踪是非常有用的。堆栈跟踪对于表示错误的异常是唯一有用的。也就是说，对于一个未经检查的例外。我认为在这种情况下，提供异常信息的底层细节不仅有用，而且是强制性的。但是我的问题涉及检查的异常，例如文件未找到。

Answer 1

没有例外不应直接在直接的错误信息给用户显示，他们是低层次的技术细节和用户几乎总是想要更多的东西可以理解的，即使它不提供尽可能多的信息作为堆栈跟踪会！

我说的几乎都是因为有这样的情况（如在集成开发环境），您可以考虑用户在技术上足以胜任看堆栈跟踪;事实上，在这种情况下，他们可能会更喜欢它“误入歧途”的错误信息。

但是，我个人认为堆栈跟踪应该始终记录在用户可以访问的某个位置，以便如果他们抱怨“该程序无法正常工作”，那么您可以确切地看到如果他们向您发送该文件会发生什么。

Answer 2

如果您向用户显示错误情况，则应该是用户友好的消息。例外包含用户不应/不需要知道的技术细节。

在某些情况下，显示堆栈跟踪信息可能是一个安全问题，所以用户不应该显示堆栈跟踪。

如果您向用户显示错误消息，有一点您有意识地决定显示一个弹出窗口，或添加一条消息到日志窗口。此时，您可以将任何异常转换为更加用户友好的消息。请注意，您可能需要比默认的Exception类型提供的更多信息，因此您可以/应该创建自己的Exception类型，其中包含向用户提供所需的所有数据所需的全部信息。

Answer 3

在一些项目中，我做了一种特殊的例外（例如UserFriendlyException）。此异常类型必须具有用户友好的错误消息。如果我发现这种异常，我可以将其显示给用户。

这使得可以使用用户友好的错误异常，并防止你表现的很技术的信息给用户。

Answer 4

我认为你不应该表现出异常消息本身给用户，它应该永远只能出现在日志中。即使您有目的地使用户友好，它仍然不会显示，因为您不能轻松国际化这些消息。您应该想出一些UI层可以理解的机制，并将其解决为可以查找国际化消息以显示给用户的代码。我发现一个带有“code”属性/枚举的异常工作得很好。非常特殊的例外也可以工作，但这可能很难维持。