何时使用 try finally 而不是 try catch finally [重复]

Question

使用 Try Catch finally 块的最佳做法是什么？你喜欢只使用 try finally 块而不是 try catch 块吗？我一直认为 try catch finally 是最好的做法。但是，在我正在使用的部分代码中，我看到了这样的代码：

试试{ 做点什么（）; } 最后{ doSomethingElse(); }

由于他们没有捕捉到异常，我很难调试代码。不使用 catch 并且只使用 finally 对我来说不是一个很好的做法，但我可能错了。

据我所知，这并不是一个好的做法。基本上，我们没有使用 try catch 的用途。我也发现了类似的questions。

我的问题是：“您是否同意我对以下假设的看法：最佳实践是一起使用 try catch finally 而不是 try finally。”如果您不同意，请您提供一个示例，说明何时使用 try finally 而不是 try catch finally，以及为什么您认为 try finally 比 try catch 更好？

Answer 1

我不同意，如果你不能对抛出的异常做任何事情，但调用者层次结构可以做一些事情，那么使用 finally 来清理你的资源，并让调用者在抛出异常后处理清理。

Answer 2

finally 构造的目的是提供始终执行的代码，即使抛出异常也是如此。

try / finally（无捕获）允许您编写保证执行的代码，即使 try 块内的代码抛出运行时异常也是如此。

这在您使用的代码可能会引发运行时异常但不会引发已检查异常的情况下非常有用。一个例子是 Spring DAO 支持；它将 IOExceptions 包装在运行时异常中。

Answer 3

通常 try-finally 用于确保执行某些代码，而不管是否发生异常。 通常缺少 Catch 块，因为 try 块中的代码不会抛出任何可以捕获的已检查异常。

例如：

try  {

        if(str.length() > 0) { // If str is null, it can throw NullPointer and hence code below it wont execute
            // some code
        }

    }finally {
        // Will be performed even if any unchecked exception is thrown
        // Must contain code which has to be performed at any cost like releasing occupied memory
    }

Answer 4

共有三种可能，try+catch、try+finally 或 try+catch+finally。它们都有自己的用途。

当您可以做一些有用的事情来处理异常时，将 catch 与 try 一起使用，例如报告发生异常的事实。

finally 块中的代码始终运行，与是否发生异常无关，因此在需要清理时将 finally 与 try 一起使用，这总是必须发生的。如果文件已成功打开，则以关闭文件为例。

Answer 5

我不同意。

try{}finally{} 应用于无法处理异常但需要清理资源的情况。

try{}finally{} 块不会像您想象的那样导致异常“消失”。它将被抛出堆栈并在其他地方处理。如果您在当前应用程序中看不到异常，那是因为它被其他地方丢弃了。

try {
    connection = createConnection();
}
finally {
    closeConnection(connection) //Free database connection.
}

在这种情况下，您可能无法处理 SQL 异常，但您仍想释放数据库连接。