答案

异常处理机制通过try-catch-finally在Java语言发展的初期就被加入。其主要目的是通过将业务代码与错误处理代码分开，提供结构化的错误管理。

问题：任何非标准或错误的行为都会导致异常的抛出（exception）。如果没有try-catch，它只能简单地传递到调用栈上游。这种方法可能会导致程序异常终止。

解决方案是使用try { } catch { } finally { }，这允许处理预期的异常并保证执行结束操作（释放资源、关闭文件、回滚事务）。

代码示例：

try {
    FileInputStream fin = new FileInputStream("test.txt");
    int data = fin.read();
} catch (IOException e) {
    System.out.println("处理文件时出错: " + e.getMessage());
} finally {
    fin.close();
}

关键特点：

try块包含潜在的错误代码
catch捕获和处理异常
finally始终会执行，即使在return/exception时也如此

陷阱问题

finally能否不执行？

可以，如果块中有System.exit()，进程异常终止，或者JVM“崩溃”了。

可以只使用try-catch而不使用finally吗？

可以，finally块不是必需的。但如果需要清理资源，通常会使用它。从Java 7开始，存在try-with-resources。

如果在finally中发生异常，会发生什么？

如果在finally中发生新的错误，它会“覆盖”原始异常（如果没有单独捕获），这可能会掩盖问题。

try { throw new RuntimeException("在try中失败"); }
finally { throw new RuntimeException("在finally中失败"); }
// 结果堆栈跟踪 — 只有 "在finally中失败"

常见错误和反模式

忽略异常 (catch(Exception e) {} 是空的)
重抛异常而不说明原因 (throw e; 没有 new Exception(e))
中断finally（返回或抛出新的异常）

生活中的例子

负面案例

在项目中，finally块包含可能抛出IOException的代码。在try中发生错误时，原始异常会完全丢失，严重妨碍错误诊断。

优点：

保证资源的释放

缺点：

错误掩盖
调试困难

积极案例

团队在finally的使用上改为使用try-with-resources。每个资源实现了AutoCloseable，释放是自动完成的，异常记录为自己的日志错误。