java异常处理的核心是可控响应与精准排查，而非消灭错误；需分层处理受检异常（强制捕获或声明）与非受检异常（优先预防）；应精准捕获、避免兜底、规范资源管理、复用标准异常、遵循早抛晚捕原则。
Java异常处理不是为了“消灭错误”，而是让程序在出错时仍能明确响应、可控降级、便于排查。真正健壮的工程代码，异常逻辑往往比业务逻辑更体现设计功底。
按类型分层处理：受检异常必须显式应对，非受检异常优先预防
受检异常（如 IOException、SQLException）由编译器强制要求处理——不是可选项，是契约。必须用 try-catch 捕获，或用 throws 向上声明。不处理无法编译通过，这是JVM对资源类外部依赖的刚性提醒。
非受检异常（如 NullPointerException、IllegalArgumentException）继承自 RuntimeException，编译器不强制捕获。它们本质是代码缺陷信号，最佳做法不是兜底捕获，而是前置校验：
- 参数为 null？提前 if (obj == null) throw new NullPointerException(...)
- 索引越界？用 Math.min(i, list.size() - 1) 或断言替代事后捕获
- 状态非法？调用前检查 if (!isReady()) throw new IllegalStateException(...)
精准捕获，拒绝“Exception e”式兜底
一个 catch (Exception e) 就像给所有病人都开同一副药——掩盖真实病因，阻碍定位。正确方式是按异常继承链“由细到粗”排列多个 catch：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 先捕 FileNotFoundException（子类），再捕 IOException（父类）
- 每个 catch 块只处理它真正能消化的异常，记录上下文（如文件路径、输入值），并选择性封装重抛
- 绝不吞掉异常：避免只写 e.printStackTrace() 或空 catch；生产环境必须经日志框架记录完整堆栈
资源管理必须用 try-with-resources，不用手写 finally
手动在 finally 里关流、关连接，极易因二次异常导致资源泄露（比如 close() 本身抛 IOException）。Java 7 引入的 try-with-resources 是标准解法：
- 自动调用 AutoCloseable.close()，无论是否异常都保证执行
- 若多个资源，关闭顺序与声明顺序相反，且异常会被抑制（可通过 getSuppressed() 获取）
- 示例：try (FileInputStream fis = new FileInputStream("a.txt"); BufferedReader br = new BufferedReader(new InputStreamReader(fis))) { ... }
自定义异常要语义清晰，复用标准异常优先
90% 的业务场景无需新建异常类。Java 标准库已提供高语义异常，直接复用更规范、更易懂：
- 参数非法 → IllegalArgumentException
- 对象状态不满足调用前提 → IllegalStateException
- 索引越界 → IndexOutOfBoundsException
- 操作不支持 → UnsupportedOperationException
确需自定义时，应继承具体标准异常（如 BusinessException extends RuntimeException），而非直接继承 Exception 或 RuntimeException；构造函数中保留 cause 参数以支持异常链，方便追溯根源。
异常传播要遵循“早抛出、晚捕获”原则
异常应在问题发生的第一时间抛出，而不是层层包装后延迟暴露：
- DAO 层读库失败，直接抛 SQLException 或封装为带业务码的 DataAccessException，不自行吞掉
- Service 层捕获底层异常后，应转换为业务语义明确的异常（如 “库存不足” 而非 “UPDATE 返回 0”），并保留原始 cause
- Controller 层才做最终拦截：统一返回友好提示给前端，同时记录完整异常链供运维分析
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
