Java何时选择已检查和未检查的异常

Java何时选择已检查和未检查的异常,第1张

Java何时选择已检查和未检查的异常

只要你知道何时应使用检查异常,它就很棒。Java核心API未能遵循SQLException(有时甚至是IOException)的这些规则,这就是它们如此糟糕的原因。

检查异常应该用于预测的,但不可预防是错误的合理歇着。

未经检查的异常应用于其他所有内容。

我将为你详细说明这一点,因为大多数人都误解了这意味着什么。

可预测但无法预防:调用方在力所能及的范围内竭尽所能来验证输入参数,但其控制范围之外的某些情况导致 *** 作失败。例如,你尝试读取文件,但是在你检查文件是否存在与读取 *** 作开始之间有人将其删除。通过声明一个检查的异常,你可以告诉调用者预期该失败。
合理地恢复:没有任何必要告诉呼叫者预见他们无法恢复的异常。如果用户尝试从不存在的文件中读取,则调用者可以提示他们输入新的文件名。另一方面,如果该方法由于编程错误(无效的方法参数或错误的方法实现)而失败,则应用程序无法采取任何措施来解决执行中的问题。最好的办法是记录问题并等待开发人员稍后解决。
除非你抛出的异常满足以上所有条件,否则应使用Unchecked Exception。

在每个级别进行重新评估:有时,捕获已检查异常的方法不是处理错误的正确位置。在这种情况下,请考虑对你自己的呼叫者而言合理的选择。如果异常是可预测的,无法预防的并且使它们恢复正常,那么你应该自己抛出一个检查的异常。如果不是,则应将异常包装在未经检查的异常中。如果遵循此规则,你会发现自己将检查的异常转换为未检查的异常,反之亦然,具体取决于你所在的层。

对于已检查和未检查的异常,请使用正确的抽象级别。例如,具有两个不同实现(数据库和文件系统)的代码存储库应避免通过抛出

SQLException
或公开特定于实现的细节
IOException
。相反,它应该将异常包装在涵盖所有实现的抽象中(例如
RepositoryException
)。



欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/5011285.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-11-14
下一篇 2022-11-14

发表评论

登录后才能评论

评论列表(0条)

保存