Java编程规范：try-catch块编写的统一风格指南

写Ja va这么多年，一个很深的体会就是：异常处理这东西，不是代码越多越安全，而是要写得准、写得少、写得有迹可循。统一风格的核心目标从来不是让代码长得一样好看，而是让责任划分清晰——异常在哪儿发生、由谁处理、怎么记录、是否要往上抛，看一眼就清楚。下面这张图就是今天要展开的核心原则。

### try块只放“真可能出错”的代码 一个try里塞进参数校验、日志打印、DTO转换、业务判断，结果就是异常信号被淹没在噪音里，排查时根本分不清是哪个环节出的问题。真正该放进try的，只有那些JVM底层或API明确会抛受检异常、或者在运行时确实容易失败的场景： * 文件读写（`FileInputStream`、`Files.readAllLines`） * 数据库操作（`JdbcTemplate.query`、`Connection.createStatement`） * 远程调用（`RestTemplate.getForObject`、`FeignClient接口调用`） * JSON序列化/反序列化（`ObjectMapper.readValue`） * 数值或时间格式解析（`Integer.parseInt`、`LocalDateTime.parse`） 其他逻辑——比如 `if (obj == null) throw new IllegalArgumentException()`、`Objects.requireNonNull()`、日志打点——统统移出try。这样既缩小了异常监控的范围，也避免了掩盖真实的问题边界。 ### catch必须具体、带日志、有动作 禁止出现 `catch (Exception e) { }` 或 `e.printStackTrace()` 这种“假处理”。每个catch块至少完成三件事： * **按继承顺序精准捕获**：`FileNotFoundException` → `IOException` → `Exception`；子类必须在父类前面，不然编译都通不过，逻辑也完全失效。 * **日志必须带原始异常和业务上下文**：用 `log.error("订单[{}]支付回调解析失败", orderId, e)`，而不是 `log.error("解析失败")`——少一个上下文信息，排查成本就翻一倍。 * **明确后续动作**：返回降级值要注释说明原因；重抛必须包装（`throw new ServiceException("支付回调异常", e)`）；静默兜底只允许极少数已经过评审的场景使用。 ### finally只做资源释放，不用它写业务逻辑 finally的唯一正当用途就是释放资源——关流、断连、解锁。现代Ja va优先用try-with-resources来替代手写finally，语义更清晰、关闭也更可靠： * 所有实现 `AutoCloseable` 的资源（`InputStream`、`Connection`、`Scanner` 等）都应该声明在try的括号里。 * 如果实在要用finally，禁止在里面写日志、调服务、改状态、return或throw。 * 特别要警惕：finally里写return会覆盖try/catch的返回值，这是非常隐蔽的逻辑陷阱，踩过的人都知道疼。 ### 分层收口，非必要不分散写try-catch Service层一般不主动捕获并吞掉异常，而是让受检异常往上抛（比如 `throws IOException`），由统一的异常处理器集中响应： * `@RestControllerAdvice` 处理Controller层的异常：业务异常转成友好提示给前端，系统异常记完整堆栈，受检异常映射到合适的HTTP状态码。 * Service方法签名显式声明受检异常，避免用 `catch (Exception e)` 一锅端——那样会掩盖底层的真实问题。 * 工具类或底层封装（比如JSON工具、文件工具）可以提供带日志和重抛的标准模板，但不能替代上层做决策。 总的来说，异常处理可以看作是代码质量的照妖镜——写得好，系统健壮、排查轻松；写得糟，埋雷无限、加班不断。照着上面的原则来，至少能保证你的try-catch块是“可以读、可以信、可以维护”的。