java处理嵌套异常的关键是责任分离、异常粒度匹配与顺序合理：catch块须从具体到宽泛排列，多捕获仅适用于逻辑一致的并列异常，嵌套应体现职责分层，而前置校验常比捕获更高效。
Java 处理复杂嵌套异常和多 catch 逻辑，关键不在“写多少层”，而在于分清责任边界、匹配异常粒度、避免逻辑重叠。
多个 catch 块的排列顺序必须从具体到宽泛
JVM 按代码中 catch 块出现的顺序依次匹配异常类型。一旦某个 catch 块能捕获当前抛出的异常（包括其子类），后续块就不再执行。
- 子类异常（如 ArithmeticException、ArrayIndexOutOfBoundsException）必须写在父类（如 RuntimeException 或 Exception）之前
- 若把
catch(Exception e)放在最前，后面所有具体异常 catch 都会失效，编译虽通过，但逻辑形同虚设 - 示例中
div(4,0)实际触发的是 ArrayIndexOutOfBoundsException（因访问 arr[4] 越界），所以只进入第二个 catch，不会走到最后一个通用 Exception 块
多重捕获（multi-catch）只适用于处理逻辑完全一致的异常
Java 7+ 的 catch(IOException | SQLException e) 是语法糖，不是万能解药。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 括号内异常类型必须互不继承（即“并列兄弟”），例如 IOException 和 SQLException 都是 Exception 的直接子类，合法；但 Exception | RuntimeException 会编译报错
- 变量 e 的静态类型是这些异常的最近公共父类（通常是 Exception），无法直接调用子类特有方法（如
e.getSQLState()） - 如果对不同异常要分别记录不同日志、做不同重试或返回不同状态码，就别强行合并，老实用多个独立 catch 更清晰可靠
嵌套 try-catch 应服务于职责分离，而非堆砌防御
外层管流程兜底，内层管资源细节——这是嵌套有意义的前提。
- 比如文件读取中，外层 catch FileNotFoundException 返回 404，内层 try-with-resources 自动关闭流时若再抛 IOException，可单独捕获并记录警告，不影响主流程
- 避免“一层 try 包裹全部业务 + 层层嵌套 catch”的写法，它会让错误定位变困难，也违背单一职责
- 更推荐方式：把易出错操作拆成小方法，各自声明明确异常；上层用统一异常处理器（如 Spring 的
@ControllerAdvice）集中响应，底层只抛不捕
统一兜底与提前校验比层层捕获更高效
很多看似复杂的异常场景，其实靠前置检查就能规避。
- 空指针？先判
if (obj == null)再操作，比等抛 NullPointerException 后捕获更轻量 - 数组越界？用
list.size()或array.length校验索引范围，而不是依赖 catch 拦截 - 除零异常？运算前判断分母是否为 0，比 catch ArithmeticException 更直观可控
- 真正需要多 catch 的，往往是跨系统交互（如 DB、HTTP、文件 IO）这类不可控外部依赖
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
