统一try-catch规范通过规则+工具+习惯系统性阻断吞异常，严禁空catch、仅printstacktrace、盲目返回默认值；强制日志带异常、finally禁业务逻辑、受检异常分类型处理，并以静态检查和全局处理器保障落地。
统一 try-catch 规范不能“消灭”吞异常，但能系统性阻断它。关键不是写更多 catch，而是用规则+工具+习惯让吞异常在编码、编译、测试阶段就无处藏身。
明确“吞异常”的三类典型表现
真正需要拦截的不是异常本身，而是以下三种危险行为：
- 空 catch 块：只写
catch (Exception e) { }，没日志、没提示、没重抛 - 仅调用
e.printStackTrace()而未接入日志框架（控制台输出在生产环境不可见） - 捕获后仅简单返回默认值（如
return null或return -1），却不记录上下文，导致上游逻辑静默失败
团队级强制规范四条铁线
不靠自觉，靠机制约束：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
禁止裸 catch：所有 catch 块必须包含至少一项有效动作——记录日志（SLF4J 的
log.error("msg", e)）、包装重抛（throw new BusinessException("xxx", e)）、或明确业务兜底（需注释说明原因） -
日志必须带原始异常：严禁只写
log.error("失败")；必须用log.error("读取配置失败", e)，保留完整堆栈 -
finally 禁止业务逻辑：只允许
close()、shutdown()类资源释放操作；禁止在 finally 中写日志、调用服务、修改状态 -
受检异常必须显式处理：对
IOException、SQLException等，不允许用catch (Exception e)一锅端，须按实际可能类型分块捕获或向上声明
落地支撑：静态检查 + 统一模板
光靠人盯效果有限，要用工具固化规范：
- 在 SonarQube 或 SpotBugs 中启用规则：
RSPEC-1166（空 catch）、RSPEC-2583（日志缺失异常参数）、RSPEC-1149（finally 含 return/throw） - 提供 IDE 活动模板（Live Template）：输入
tc自动展开为带 SLF4J 日志和 re-throw 的标准 catch 块 - Service 层方法签名强制声明受检异常，避免隐式吞掉底层 IO/SQL 异常
替代方案：用全局异常处理器收口
非必要不分散写 try-catch。Controller 层统一交由 @RestControllerAdvice 处理：
- 业务异常（
BusinessException）→ 返回友好错误码和提示 - 系统异常（
RuntimeException）→ 记录完整堆栈并返回通用错误 - 受检异常（如
IOException）→ 在 Service 接口抛出，由全局处理器转为对应 HTTP 状态码
这样既减少重复代码，又确保每类异常都有可追溯、可监控、可告警的统一出口。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
