在finally块中抛出异常会导致性能问题吗?

Stu*_*ava 13 java performance exception-handling exception

在Rational Application Developer(基于eclipse的RAD)中,在软件分析器下,我看到一个代码审查注释(在Performance => Memory部分下),说"避免最终的throw语句".

如何在finally块中定义throw会影响性能?

在此输入图像描述

这是代码片段,我们已经建议更改代码以记录异常跟踪并且不抛出异常,

     } finally {
        if (bufferedReader != null) {
            try {
                bufferedReader.close();
            } catch (final IOException ex) {
                throw ex;
            }
        }
    }
Run Code Online (Sandbox Code Playgroud)

我只是想知道这会如何影响内存和性能?

eri*_*son 6

finally块中抛出的异常将替换从中抛出的任何异常try,并且可能丢失有关真实问题的信息.

由于在这种情况下try-finally块被允许抛出IOException,这里有一个更好的方法来编写它:

try (BufferedReader bufferedReader = Files.newBufferedReader(Paths.get("file.txt"))) {
  /* Work with `bufferedReader` */
}
Run Code Online (Sandbox Code Playgroud)

这会在块退出时自动关闭阅读器,并且很好地处理任何结果异常,即使try块内的代码首先使用"抑制"机制抛出自己的异常Throwable.

如果try块完成无异常,则结果将是关闭资源的结果(异常与否).如果try块抛出异常,那将是异常结果.但是,如果该close()方法也引发异常,它将try作为"抑制"异常添加到块的异常中.您可以以编程方式查询它,并且在打印堆栈跟踪时,将显示被抑制的异常,就像您可能更熟悉的"由...引起的"异常一样.

并且,您可以尝试使用多种资源; 这些都将被关闭,并且可以抑制多个闭包异常.

这假设您正在使用文件I/O,但相同的"try-with-resources"结构将适用于实现的任何内容AutoCloseable(流,SQL对象等).

  • 仍然没有答案的是,对性能的影响在哪里.我实际上相信警告只是错误的. (2认同)

Par*_*dox -1

最后用于抛出/捕获异常之后。因此根据设计,finally 中不需要抛出异常。这应该只在您的 try 块中完成。

可能会帮助您了解有关 Java 中的 try-catch-finally 异常处理的更多信息

  • finally 块**总是**执行,即使 try 块**没有**抛出异常。 (3认同)