应避免多层门面中层层try-catch，正确做法是让异常逐层透传至统一处理层（如@controlleradvice），dao层抛原始异常、service层仅转换业务相关异常、controller层不主动捕获，配合@transactional、@valid等声明式机制实现轻量、清晰、高性能的异常流。
Java中多层门面（Facade）架构下，层层try-catch不是语法错误，而是设计隐患——它既放大异常处理开销，又掩盖真实问题边界。真正要避免的不是“用不用try-catch”，而是“在哪用、怎么用、用多少”。核心思路是：让异常流动起来，而不是在每一层都截停、打印、再抛出。
把异常交给该负责的人
门面层本应聚合、协调、简化调用，而非充当异常收容所。常见反模式是：Controller → Service → Dao 每一层都加一套 try-catch，各自记录日志、包装异常、再 throw new BusinessException(...)。结果是同一异常被多次构造、多次堆栈填充、多次序列化。
- Dao 层只抛原始数据访问异常（如 SQLException、DataAccessException），不捕获也不包装
- Service 层专注业务校验与事务语义，仅捕获并转换**影响业务决策**的异常（例如库存不足、余额不足），其他异常直接透传
- Controller 或网关层统一拦截所有未处理异常，做响应封装、审计日志、告警触发——这才是异常的“终点站”
用声明式替代命令式异常处理
Spring 等框架已提供成熟机制，无需手动嵌套：
- @Transactional 注解自动管理事务边界和回滚规则，避免在 service 方法里写 try-catch 控制 rollbackOnly
- @ControllerAdvice + @ExceptionHandler 集中处理特定异常类型，比如统一将 DataAccessException 转为 500 响应，无需每个 controller 方法都写 catch
- @Valid + BindingResult 取代手动 if-else 校验 + 手动抛异常，校验失败走统一错误路径
警惕“伪容错”式循环内 try-catch
门面常需批量处理（如导入1000条数据），若在 for 循环内每条都套 try-catch，性能损耗会随数据量线性增长——尤其在 JDK 8~17 中，虽然 JVM 对 try 块入口开销已大幅优化，但异常对象创建+堆栈填充仍不可忽视。
- 单条失败不影响整体时：用循环内 try-catch，但 catch 中只做最小动作（如记录错误索引、跳过当前项），避免日志刷屏或远程调用
- 强一致性要求（全成功或全失败）：把整个批量操作包进一个外层 try，失败即中断，靠事务或补偿机制保证原子性
- 混合场景：先 validate 再 execute，把可预判的失败（格式错误、必填缺失）挡在执行前，减少真正抛异常的次数
资源管理别靠 finally 堆叠
多层门面中常伴随多层资源打开（HTTP client、DB connection、文件流），传统写法易导致嵌套 try-finally 或 try-catch-finally 套娃。
- 一律使用 try-with-resources：只要资源实现 AutoCloseable，一行声明即可自动释放，无需嵌套或 finally
- 第三方 SDK 不支持 AutoCloseable？封装一层适配器，或改用连接池/客户端自带的上下文生命周期管理（如 WebClient 的 Mono/Flux 自动清理）
- 避免在门面方法里直接 new FileInputStream、new Socket——这些应由底层组件封装，门面只依赖抽象接口
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
