java – 为什么应该尝试在已检查的异常上抛出未经检查的异常?
参见英文答案 >
The case against checked exceptions32个
我被告知我应该考虑在我的代码中对Checked异常抛出Unchecked异常而不仅仅是这样,而是用我自己的扩展RuntimeException. 现在,我确实理解了两者之间的区别,但仍然不明白我为什么要这样做? 如果我有这个方法标题,抛出2种异常: public static Optional<String> getFileMd5(String filePath) throws NoSuchAlgorithmException,IOException {} 为什么我要用一个(不太详细)的例外替换它们? 解决方法
IOException是可以接受的.调用者无法确定filePath是否存在,并且在执行该方法时仍然存在,并且您的方法必须能够发出问题的信号.在这种情况下抛出IOException是常规异常,但如果您喜欢运行时异常,可以将其包装在
UncheckedIOException内.未经检查的IO异常与已检查的IOException一样清晰.你会失去(或获得,取决于观点)是你不会强迫呼叫者处理它.
另一方面,NoSuchAlgorithmException异常应该包含在运行时异常中.如果您的方法使用不存在的算法,则调用者无法执行任何操作.如果发生异常,这显然是一个错误,并且应该通过运行时异常来发出错误信号.因此,编写自己的运行时异常,包装原始的NoSuchAlgorithmException(这样,如果你抛出它就不会丢失问题的根本原因),并且不要打扰代码的所有调用者.永远不会发生. 关于运行时与已检查的异常,它主要是基于意见的问题,但应该注意以下几点: > AFAIK,没有新的Java API再使用已检查的异常.例如,请参阅java.time,它永远不会抛出已检查的异常,尽管旧的等效项(如DateFormat)会抛出已检查的异常 我认为现在可以说,检查异常是一个有趣的想法,但事实证明这是个坏主意.你应该更喜欢unchecekd例外. 现在,如果您的问题是:如何抛出未经检查的异常而不是检查异常,这很简单: public static Optional<String> getFileMd5(String filePath) { try { // your original code } catch (IOException e) { throw new UncheckedIOException(e); } catch (NoSuchAlgorithmException e) { throw MyCustomCryptoException(e); } } (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |