java异常处理本质是将不可控意外转为可控分支逻辑，区分checked异常（强制处理外部依赖失败）与unchecked异常（应预防而非捕获），并用try-with-resources等机制保障资源安全，核心在于业务语义判断而非语法技巧。
Java中使用异常处理，根本目的不是“让程序不报错”，而是把**不可控的意外事件，变成可控的分支逻辑**——它本质是一种错误控制的设计契约，而非补救手段。
为什么不能靠if-else提前检查所有错误？
有些错误根本无法在执行前预判。比如：FileReader打开文件时抛出的FileNotFoundException，不是因为代码写错了，而是文件可能被另一个进程删除、权限被回收、网络存储临时离线。这些属于外部状态，if判断永远漏判。
- 用
file.exists()+file.canRead()双重校验，仍无法避免“检查完瞬间被删”的竞态问题 -
new Socket(host, port)能否连上？DNS解析、防火墙、服务端崩溃……全在运行时才揭晓 - 数据库连接池返回的
Connection对象，调用createStatement()时才可能触发SQLException
异常类型划分直接决定你“必须怎么写”
Java强制用编译器介入区分两类异常：编译时异常（checked）和运行时异常（unchecked）。这不是设计冗余，而是明确责任归属。
-
IOException、SQLException等checked异常：编译器会报错，逼你做选择——要么try-catch当场消化，要么用throws向上移交。这是对“外部依赖失败”这一事实的严肃声明 -
NullPointerException、ArrayIndexOutOfBoundsException等unchecked异常：编译器不管，但它们暴露的是**代码缺陷**。你不该捕获它们来兜底，而该用Objects.requireNonNull()、边界检查、Optional等手段从源头预防
混淆这两类，比如对NullPointerException写空catch块，等于把bug藏进黑盒。
立即学习“Java免费学习笔记（深入）”；
finally和try-with-resources不是可选项，是资源安全底线
文件流、数据库连接、Socket套接字这些资源，不显式关闭就会泄漏。而程序可能在任意位置抛异常中断流程——finally或try-with-resources是唯一能保证清理逻辑必达的机制。
try (FileInputStream fis = new FileInputStream("data.bin");
BufferedInputStream bis = new BufferedInputStream(fis)) {
// 读取操作
} catch (IOException e) {
// 异常处理
}
// fis 和 bis 自动关闭，无论是否发生异常
- 手动写
finally关资源容易出错：比如close()自己又抛异常，会掩盖原始异常 -
try-with-resources要求资源实现AutoCloseable，否则编译不通过——这是编译器帮你卡住资源管理漏洞
真正难的不是语法，是判断“这个异常我该吞掉、该转义、该重试、还是该立刻终止”。比如网络超时该重试三次，而SQL主键冲突该转成用户友好的提示——异常处理的深度，取决于你对业务边界的理解，而不是对catch关键字的熟练度。
