业务与技术异常分离，提升Java代码可维护性

本文深入探讨了Java开发中业务异常与技术异常分离设计的核心原则，强调业务异常必须使用RuntimeException子类而非受检异常（如Exception及其子类），以避免强制调用方冗余处理、割裂业务逻辑与错误处理职责，真正践行“谁出错谁负责”的设计哲学；通过剖析OrderException等典型误用案例，揭示了滥用受检异常导致的代码臃肿、可读性下降和维护成本飙升问题，并指出业务异常应严格限定在明确的业务规则校验点（如金额为负、库存不足）精准抛出，从而显著提升系统可维护性、可测试性与协作效率——这不仅是异常处理的规范，更是面向领域建模的代码洁癖实践。

业务异常该用 RuntimeException 还是受检异常？

业务异常必须用 RuntimeException 子类，不能用 Exception 或其子类（如 IOException）。否则调用方被迫写一堆 try-catch 或向上抛，把业务逻辑和错误处理缠在一起，违背“谁出错谁负责”的边界原则。

常见错误现象：定义了 OrderException extends Exception，结果每个 service 方法签名都带 throws OrderException，最后 controller 里全是模板化 catch，根本没法区分是参数错、库存不足还是支付超时。

• 业务异常只在明确的业务规则断点抛出，比如 if (order.getAmount()
• 所有业务异常统一继承自一个基类，如 BusinessException，方便全局捕获和统一响应格式
• 不要给业务异常塞技术细节（如堆栈、SQL语句），它只回答“为什么不能继续”——例如“优惠券已过期”，而不是“MySQL connection timeout”

技术异常怎么避免污染业务代码？

技术异常（如 SQLException、HttpClientErrorException）必须在最靠近资源的地方捕获并转换，绝不能让它穿透到 service 或 controller 层。

使用场景：调用第三方 HTTP 接口失败、数据库连接中断、Redis 写入超时。这些不是业务规则问题，而是基础设施不稳定，业务层不该也不需要知道重试几次、要不要降级。

• DAO 层或 client 层 catch SQLException / RestClientException，转成对应的 DatabaseAccessException 或 ThirdPartyServiceUnavailableException（二者都应是 RuntimeException 子类）
• 转换时保留原始异常作 cause：throw new DatabaseAccessException("failed to update order status", e);，便于排查但不暴露给前端
• 不要在 service 方法里直接 catch SQLException——这说明数据访问逻辑没封装好，DAO 层职责被架空

@ControllerAdvice 捕获时如何区分业务异常和技术异常？

全局异常处理器必须按类型分治，否则一个 @ExceptionHandler(Exception.class) 就会让所有错误返回 500，连参数校验失败都变服务器错误。

参数差异：业务异常走 4xx 状态码 + 业务提示；技术异常走 5xx + 日志告警 + 可选降级响应。

• 单独写 @ExceptionHandler(BusinessException.class)，返回 HttpStatus.BAD_REQUEST 或 HttpStatus.CONFLICT，body 含 code 和 message 字段
• 另写 @ExceptionHandler(DatabaseAccessException.class) 等具体技术异常，记录 error 日志，返回 HttpStatus.SERVICE_UNAVAILABLE，body 中 message 固定为“系统繁忙，请稍后重试”
• 兜底的 @ExceptionHandler(RuntimeException.class) 只捕获未分类的 RuntimeException，打 warn 日志并返回 500，防止漏掉新异常类型

日志里怎么一眼看出是业务卡点还是系统故障？

关键不是记多少条日志，而是让每条日志自带上下文标签。业务异常日志不打 ERROR 级别，技术异常不省略 traceId。

性能影响：过度打日志会拖慢高并发接口，但漏掉关键标识会让线上问题排查时间翻倍。

• 业务异常统一用 log.warn("business rule violated: {}", e.getMessage(), e) —— warn 级别+带 message，不带堆栈（除非要调试规则逻辑）
• 技术异常必须 log.error("db access failed, orderId={}", orderId, e) —— error 级别+关键业务字段+完整堆栈
• 所有日志开头加 MDC 字段，如 MDC.put("traceId", request.getHeader("X-Trace-ID"))，否则分布式链路一断就找不到根因

真正难的是坚持——每次加新校验、调新接口时，都要下意识问一句：这个错，是用户能改的，还是得运维上机器看的？答错一次，后续补日志、改状态码、调监控，成本就远不止加一行 throw。

今天关于《业务与技术异常分离，提升Java代码可维护性》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！