微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

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)会抛出已检查的异常
> Java是唯一检查异常的语言.
>检查的异常不适合Java 8中引入的功能习惯用法(lambda表达式,流等):没有功能接口抛出已检查的异常.

我认为现在可以说,检查异常是一个有趣的想法,但事实证明这是个坏主意.你应该更喜欢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);
    }
}

原文地址:https://www.jb51.cc/java/129522.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐