Clean Code/代码简洁性Good-Practice：使用统一异常来取代错误处理

通过自定义异常集中处理，将繁琐的参数校验代码转化为清晰、简洁且可维护的艺术。

在Java开发中，参数校验、业务校验等错误情况处理是保证程序健壮性和数据完整性的第一道防线。我们常常会看到代码中充斥着大量的 if条件判断语句来进行参数校验，每个校验逻辑后通常还伴随着类似的错误处理和日志记录。这种重复不仅使代码变得臃肿冗长，还极大地降低了可读性和可维护性。

本文将以一个具体的参数校验代码改造为例，探讨如何利用统一异常处理机制，显著提升代码的简洁性与优雅度。

一、原始代码：冗余的校验与重复的处理

观察改造前的代码，我们发现每个参数校验都遵循着相同的模式：

if (ObjectUtils.isEmpty(funCode)) {log.info("商户API前置请求参数错误返回【接口编码为空】,reqId={}", reqId);resMap.setResCode(Constant.ERROR_6001);resMap.setResMsg("【参数错误】接口编码为空");response.getWriter().write(JsonUtils.toJson(resMap));return;
}if (isReqOverLimit(merId, funCode)) {log.info("商户API前置请求,接口次数超限!接口={},商户号={},reqId={}", funCodeEnum.name(), merId, reqId);resMap.setResCode(Constant.ERROR_6042);resMap.setResMsg(Constant.ERROR_MSG_6042);response.getWriter().write(JsonUtils.toJson(resMap));return;
}// ... 其他多个类似的参数校验块

这种传统处理方式存在几个明显问题：

代码重复严重：相同的错误码设置、响应写入和日志记录逻辑在每个条件判断中重复出现。
关注点混淆：业务逻辑（参数校验）与技术细节（响应构建、日志记录）紧密耦合。
可维护性差：如果需要修改错误响应格式或日志记录方式，必须修改多处代码，容易遗漏且繁琐。

这种代码结构违反了 DRY（Don't Repeat Yourself）原则，是代码优化中首要解决的问题。

二、改造方案：统一异常处理的威力

改造的核心思想是：将参数校验失败视为一种异常情况，通过抛出特定的异常来中断正常流程，并在一处集中处理这些异常。

1. 改造校验逻辑——抛出异常

将原有的 if 条件判断改为抛出异常，代码立刻变得清晰简洁：

try {String funCode = requestMessage.getFunCode();if (ObjectUtils.isEmpty(funCode)) {throw BizException.build(Constant.ERROR_6001, "【参数错误】接口编码为空");}if (ObjectUtils.isEmpty(requestMessage.getReqData())) {throw BizException.build(Constant.ERROR_6001, "【参数错误】请求数据为空");}String merId = requestMessage.getMerId();if (ObjectUtils.isEmpty(merId)) {throw BizException.build(Constant.ERROR_6001, "【参数错误】商户号为空");}if (ObjectUtils.isEmpty(requestMessage.getVersion())) {throw BizException.build(Constant.ERROR_6001, "【参数错误】版本信息为空");}if (ObjectUtils.isEmpty(requestMessage.getSign())) {throw BizException.build(Constant.ERROR_6001, "【参数错误】签名为空");}if (isReqOverLimit(merId, funCode)) {log.info("商户API前置请求,接口次数超限!接口={},商户号={},reqId={}", funCodeEnum.name(), merId, reqId);throw BizException.build(Constant.ERROR_6042, Constant.ERROR_MSG_6042);}// ... 其他多个类似的参数校验块} catch (BizException e) {log.error("商户API前置请求业务失败,reqId={},{}-{}", reqId, e.getCode(), e.getMessage());resMap.setResCode(e.getCode());resMap.setResMsg(e.getMessage());response.getWriter().write(JsonUtils.toJson(resMap));return;
}

2. 自定义业务异常

BizException是一个简单的业务异常类，封装错误码和错误信息：

public class BizException extends RuntimeException {@Getterprivate String code;private BizException(String code, String message) {super(message);this.code = code;}public static BizException build(String code, String message) {return new BizException(code, message);}
}

这样改造的主要优势：

校验逻辑纯净了：if 语句只关心检查条件并抛出异常，职责单一。
消除了重复代码：错误处理逻辑只在一处（catch 块）实现，符合DRY原则。
代码可读性提高：业务主线更加清晰，不会被大量的错误处理代码所淹没。

三、为何这样能提升代码简洁性？

遵守 DRY 原则（Don't Repeat Yourself）：通过将重复的错误处理逻辑抽取到一处（自定义异常），消除了代码冗余。
关注点分离（Separation of Concerns）：业务代码只关注是否校验通过，异常处理则专注如何应对校验失败。这种分离使代码结构更清晰，更易于理解和维护。
使用异常控制流程：对于像参数错误这类"异常"情况，利用 Java 的异常机制来中断当前流程是更自然、更清晰的做法，避免了多层嵌套的 if-else 语句。
提升可读性：代码的主干逻辑（校验通过后要做什么）变得更加突出，不会被大量的错误处理代码所淹没。