参见英文答案 >
The case against checked exceptions32个
我被告知我应该考虑在我的代码中对Checked异常抛出Unchecked异常而不仅仅是这样,而是用我自己的扩展RuntimeException.
现在,我确实理解了两者之间的区别,但仍然不明白我为什么要这样做？
我被告知我应该考虑在我的代码中对Checked异常抛出Unchecked异常而不仅仅是这样,而是用我自己的扩展RuntimeException.
现在,我确实理解了两者之间的区别,但仍然不明白我为什么要这样做？
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);
}
}
