处理io流时需按继承关系从子类到父类排列catch块，如filenotfoundexception→ioexception→exception；同级无继承关系异常可用multi-catch合并；优先使用try-with-resources自动释放资源；避免用exception兜底掩盖问题。
处理 IO 流时，常需应对多种异常（如 FileNotFoundException、IOException），而多 catch 块是保障健壮性的关键手段。核心在于：按异常粒度从细到粗排列、避免兜底过早、合理利用 multi-catch 简化共性逻辑。
IO 异常类型必须按继承关系从子类到父类排列
IO 操作可能抛出的异常存在明确继承链：FileNotFoundException ⊂ IOException ⊂ Exception。若顺序写反，编译直接失败。
- ✅ 正确写法：先捕获具体异常，再捕获泛化异常
-
catch (FileNotFoundException e)→catch (IOException e)→catch (Exception e) - ❌ 错误写法：把
Exception放在IOException前，后者永远不可达，编译报错 “exception IOException has already been caught” - 实际中常见错误是 IDE 自动补全或重构时未检查顺序，导致后续 catch 块失效
同级异常可用 multi-catch 合并，但需满足“无继承”前提
当多个异常处理逻辑完全一致（如统一记录日志后抛出自定义异常），且彼此无继承关系，可用 | 合并。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- ✅ 合法示例：
catch (IOException | SQLException e)，二者都直接继承Exception，互为兄弟类 - ❌ 非法示例：
catch (Exception | RuntimeException e)，因后者是前者子类，编译报错 “Alternatives cannot be related by subclassing” - multi-catch 中的异常变量
e是隐式final，其静态类型为最近公共父类（如Exception），不能调用子类特有方法 - 适合场景：文件读取 + 数据库写入组合操作中，IO 和 SQL 异常都需回滚事务并记录错误
资源释放优先用 try-with-resources，而非手动 finally
IO 流对象（如 FileInputStream、BufferedReader）实现 AutoCloseable，应优先使用 JDK 7+ 的 try-with-resources 语法。
- 自动调用
close()，无论是否发生异常，无需手写finally块 - 即使 try 块中抛出异常，资源仍会被关闭；若关闭过程也抛异常，会作为抑制异常（suppressed exception）附加到主异常上
- 避免传统
try-catch-finally中因fw为 null 导致的空指针风险，也省去判空和嵌套 try-catch - 示例：
try (FileReader fr = new FileReader("a.txt")) { ... }，fr 在作用域结束时自动关闭
不要用 Exception 兜底掩盖真实问题
虽然语法允许 catch (Exception e) 放在最后，但生产代码中应谨慎使用。
- 它会拦截所有未显式捕获的运行时异常（如
NullPointerException、ArrayIndexOutOfBoundsException），掩盖编程缺陷 - 真正需要的是：对已知可恢复异常做针对性处理（如重试、降级），对不可控异常记录完整堆栈并快速失败
- 若必须兜底，至少保留
e.printStackTrace()或使用日志框架输出e全量信息，而非静默吞掉 - 建议用
catch (Throwable t)仅用于最外层全局异常处理器，且需区分Error与Exception
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
