多catch块必须按“从具体到抽象”顺序排列，如FileNotFoundException→IOException→Exception；可合并无继承关系的异常（如|语法），但e为公共父类类型；每个catch需明确响应动作，兜底catch放最后且不可省略日志。
多catch块的写法直接影响代码是否容易看懂、改得动、查得快。核心不是堆砌语法，而是让异常处理逻辑一目了然。
按“从具体到抽象”排列catch顺序
这是编译器强制要求，更是可读性的基础。JVM自上而下匹配，把最明确的异常放在最前面，读者一眼就能知道“这个try里主要防哪些具体问题”。比如文件操作中，FileNotFoundException比IOException更具体，应该写在它前面；IOException又比Exception更具体，也应前置。
- 错误示例：catch(Exception e) 写在 catch(NullPointerException e) 前 → 编译失败，且逻辑被掩盖
- 正确结构：每个catch块对应一个清晰的失败场景，如“路径错”“没权限”“读取中断”“其他意外”
- 兜底的 catch(Exception e) 或 catch(Throwable t) 必须放在最后，仅作收尾，不能替代具体处理
合并语义一致的异常类型
当多个异常需要执行完全相同的处理动作（比如统一记录日志、封装后抛出），用JDK 7+的multi-catch语法能显著减少重复代码。
- 合法写法：catch(FileNotFoundException | SecurityException e)
- 非法写法：catch(IOException | FileNotFoundException e) → 因为后者是前者的子类，编译报错
- 注意：合并后的异常变量e的类型是它们的最近公共父类，只能调用该父类声明的方法
每个catch块要有明确意图和有效动作
可读性差的catch往往源于空处理、泛泛而谈或过度兜底。每个块都该回答一个问题：“这个异常发生时，程序要做什么？”
立即学习“Java免费学习笔记（深入）”；
- 避免空catch或只写e.printStackTrace()，至少输出带上下文的提示，比如“配置文件[app.yml]加载失败：” + e.getMessage()
- 不同catch块之间不要做相似的日志格式，但内容要区分——越靠前的块，信息越具体、修复指引越直接
- 不建议用一个catch(Exception e)包打天下，那样等于放弃异常分类带来的诊断价值
配合finally或try-with-resources提升结构清晰度
资源清理逻辑如果混在catch里，会让错误处理主线变得模糊。把释放文件流、数据库连接等操作单独拎出来，主干逻辑更干净。
- 优先使用try-with-resources（JDK 7+），自动关闭AutoCloseable资源，无需手动写finally
- 若必须用finally，确保里面不抛新异常，也不依赖try/catch中的变量状态
- 资源获取与异常处理分离后，每个catch块专注“出错了怎么办”，而不是“还要关什么”
