考虑一些可能引发检查异常(类型为的异常Exception)的代码。catch当然,您的代码是例外。您也不只是吞下该异常,您的代码还可以通过您的用户界面以某种方式向用户报告该异常。也许在日志文件中,或使用GUI弹出窗口。您报告给用户的文本应包含异常的消息文本。也就是说,由Throwable.getMessage()或提供的文本Throwable.getLocalizedMessage()?我认为不是,但是似乎很多人不同意我的看法。那我怎么了?我的论据如下。该消息是在引发异常时创建的。因此,它充其量只能提供非常低级的信息,可能不适合向用户报告。从哲学上讲,在我看来,使用消息与异常的整体观点相抵触,即将错误处理的检测和启动(throw部分)与处理和报告的完成(部分)分开catch。使用该消息意味着该消息必须能够很好地进行报告,从而将报告的责任转移到仅应负责检测和启动的位置。也就是说,我认为getMessage()设计的一部分Throwable是错误的。该消息未本地化。尽管它的名字getLocalizedMessage()很好,但不是很好,因为您可能要等到您catch例外时才知道要使用什么语言环境(是要转到英语系统管理员阅读的系统日志的报告,还是要在窗口中弹出以查看GUI的法语用户?)。我听说Java 7为改进了异常层次结构IOException,使您能够处理不同catch子句中的各种I / O错误,从而使getMessage()文本的重要性降低。这意味着即使Java设计人员也对它不满意getMessage()。我不是问报告堆栈跟踪是否有用。堆栈跟踪只会对提示错误的异常有用。也就是说,对于未经检查的异常。我认为在这种情况下,提供异常消息的低级详细信息不仅有用,而且是强制性的。但是我的问题涉及已检查的异常,例如文件未找到。
3 回答

慕莱坞森
TA贡献1810条经验 获得超4个赞
如果向用户显示错误情况,则可能应该是用户友好的消息。例外包含用户不应该/不需要知道的技术细节。
在某些情况下,显示堆栈跟踪信息可能是出于安全考虑,因此永远不要向用户显示堆栈跟踪。
如果要向用户显示错误消息,则有些时候您有意识地决定显示弹出窗口或将消息添加到日志窗口。那时,您可以将任何异常转换为更用户友好的消息。请注意,您可能需要比默认Exception
类型提供的更多的信息,因此您可以/应该创建自己的Exception
类型,其中包含所需的所有信息,以向用户提供所需的所有数据。

米脂
TA贡献1836条经验 获得超3个赞
不,异常不应直接在错误消息中直接显示给用户,它们是低级的技术细节,并且用户几乎总是希望获得更易于理解的内容,即使它所提供的信息不如堆栈跟踪所能提供的那么多!
我几乎总是说这是因为在某些情况下(例如在IDE中),您可以认为您的用户在技术上足以胜任查看堆栈跟踪的能力。的确,在这种情况下,他们可能会更喜欢它,而不是“沉迷”的错误消息。
但是,就我个人而言,我认为堆栈跟踪应该始终记录在用户可以访问的位置,这样,如果他们抱怨“程序无法正常工作”,则可以确切地知道如果向您发送该文件,会发生什么情况。

江户川乱折腾
TA贡献1851条经验 获得超5个赞
在某些项目中,我做出了一种特殊的异常(例如UserFriendlyException)。此异常类型必须具有用户友好的错误消息。如果发现此类异常,则可以向用户显示。
这样就可以将异常用于用户友好的错误,并防止您向用户显示非常技术性的消息。
添加回答
举报
0/150
提交
取消