Java异常分离设计：业务与技术区分技巧

目前golang学习网上已经有很多关于文章的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《Java业务异常与技术异常分离设计》，也希望能帮助到大家，如果阅读完后真的对你学习文章有帮助，欢迎动动手指，评论留言并分享~

业务异常必须用 RuntimeException 子类，不可用 Exception 及其子类；否则强制调用方处理，混淆业务逻辑与错误处理，违背“谁出错谁负责”原则。

业务异常该用 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学习网公众号！