Java中多个catch块重复逻辑的本质是异常分类处理与共性操作分离不当，应提取公共处理（如日志、回滚、统一返回）、利用异常继承体系合并捕获、采用try-with-resources减少资源相关catch、并通过策略模式下沉差异化处理。
Java中多个catch块的重复逻辑，本质是异常分类处理与共性操作分离不当的问题。核心思路是把公共处理提取出来，按需保留差异化分支，而不是简单合并或删减。
识别可复用的公共处理逻辑
多个catch块里反复出现的日志记录、资源清理、统一返回值构造等，都是典型的可提取内容。比如：
- 每个catch都调用了
log.error("操作失败", e) - 都执行了
rollbackTransaction()或closeConnection() - 最终都封装成
Result.failure(e.getMessage())
这些不是“异常类型不同”，而是“处理动作雷同”。只要不影响业务语义，就该优先上提。
用Exception的层级关系合并同类catch
Java异常继承体系天然支持向上兼容。若IOException和SQLException都需要同样兜底处理，可直接捕获它们的共同父类Exception；若只想覆盖部分，选更近的公共祖先，如RuntimeException或自定义基类。
立即学习“Java免费学习笔记（深入）”；
- 避免写
catch (IOException e) { ... } catch (SQLException e) { ... }这种并列结构 - 改用
catch (SQLException | IOException e) { ... }（Java 7+多异常捕获语法） - 若还需区分特定异常做额外动作，再在统一catch内用
instanceof判断
用try-with-resources替代手动close + 多层catch
资源泄漏常导致额外catch块用于关闭操作。使用try-with-resources后，自动关闭会抑制异常传播，大幅减少因close()失败而追加的catch。
- 原写法需两个catch：一个处理业务异常，一个处理
close()抛出的IOException - 改用
try (FileInputStream fis = new FileInputStream(...)) { ... }后，close由JVM保证，异常只来自业务逻辑 - 配合
addSuppressed()机制，原始异常仍可追溯，不丢失上下文
将差异化处理下沉到策略或模板方法
当不同异常确实需要不同响应（如IllegalArgumentException返回400，IOException重试，SecurityException拒绝访问），硬编码在catch里易膨胀。更适合抽象为策略：
- 定义接口
ExceptionHandler<T extends Throwable>，实现类各自处理对应异常 - 用Map或ServiceLoader注册映射关系：
handlers.get(e.getClass()).handle(e) - 主流程只保留一个catch，委托给策略分发器，扩展新异常类型无需改主逻辑
不复杂但容易忽略
