相关疑难解决方法(0)

考虑一些可以抛出已检查异常的代码(类型异常Exception).catch当然,你的代码是个例外.您不仅要吞下异常,您的代码也会通过您的用户界面以某种方式向用户报告.或许在日志文件中,或使用GUI弹出窗口.

您向用户报告的文本是否应包含例外的消息文本.也就是说,通过提供的文本Throwable.getMessage()或Throwable.getLocalizedMessage()？

我想不是,但似乎很多人不同意我的意见.那我错了什么？我的论点如下.

• 抛出异常时创建了消息.因此,它最多只能提供非常低级别的信息,这可能不适合向用户报告.
• 从哲学上讲,在我看来,使用这个消息反对整个异常点,即将错误处理(throw部分)的检测和启动与处理和报告的完成(部分)分开catch.使用该消息意味着该消息必须适合于报告,这将报告的责任转移到应该仅负责检测和启动的位置.也就是说,我认为getMessage()设计的一部分Throwable是错误的.
• 邮件未本地化.尽管它的名字,但是getLocalizedMessage()不是很好,因为你可能不知道你想要使用什么语言环境,直到你catch的异常(报告转到你的英语系统管理员读取的系统日志,或者是否在窗口弹出GUI的法国用户？).
• 我听说Java 7有一个大大改进的异常层次结构IOException,使您能够处理不同catch子句中的不同类型的I/O错误,使getMessage()文本不那么重要.这意味着即使Java设计师也有点不舒服getMessage().

我不是在询问报告堆栈跟踪是否有用.堆栈跟踪仅对建议错误的异常有用.也就是说,对于未经检查的异常.我认为在这种情况下提供异常消息的低级细节不仅有用而且是强制性的.但我的问题涉及已检查的异常,例如file-not-found.

在什么特定情况下,可以(甚至推荐)向生产系统上的UI提供StackTrace的最终用户.

有大量的网站和SO文章,人们会问他们是否应该向最终用户展示StackTraces.毫不奇怪,答案是响亮的"不!" .

例如:

• Java:我们通常不希望向用户显示错误堆栈跟踪中的哪些信息？
• java:在生产环境中使用printStackTrace
• 我应该打印异常堆栈跟踪吗？
• 何时记录捕获的异常的堆栈跟踪

但是,我最近与另一位开发人员进行了对话,在那里我花了很多时间来确定为什么堆栈跟踪不应该通过UI传递给用户.那次讨论让我回过头来重新审视我的一个基本(绝对)租户 - 用户永远不会看到生产中的原始StackTrace.

我找不到一个令人信服的理由.但是,我确信有有效的用例,我想要理解它,或者继续坚持我的绝对租户.

我最近询问是否要报告getMessage()被捕异常的文本.相当令人惊讶的是,大多数答案误解了我的问题并认为我在询问是否报告了捕获异常的堆栈跟踪,这表明这样做被认为是常态.所以我要问一个跟进问题.

在您catch遇到异常时,您应该在哪种情况下或者不应该报告堆栈跟踪？通过"报告",我包括要求日志框架为您记录堆栈跟踪.

我不是在问一些事情.我在问这个报告是否应该包含堆栈跟踪.