17370845950

Java异常处理应统一封装、复用自定义异常基类、配合全局处理器@ControllerAdvice，避免重复try-catch；定义含错误码枚举的BaseException基类，重载构造函数并重写getMessage；工具类封装校验逻辑；保留异常链路与上下文，过滤敏感信息，确保异常成为可读可控的业务信号。

Java异常处理中减少重复代码，核心在于统一异常封装、合理复用自定义异常类、配合全局异常处理器，避免在每个方法里重复写try-catch-log-throw逻辑。

统一定义业务异常基类

所有业务异常继承一个公共基类（如BaseException），它本身继承RuntimeException，并携带错误码、提示信息、可选的原始异常等字段。这样后续新增异常只需扩展该基类，无需重复定义共性结构。

• 错误码建议用枚举管理（如ErrorCode.USER_NOT_FOUND），避免字符串硬编码
• 构造函数重载：支持仅传码、传码+参数占位符、传码+参数+cause等多种调用方式
• 重写getMessage()，自动填充国际化消息或格式化后的提示语

用@ControllerAdvice + @ExceptionHandler做全局捕获

Spring项目中，把通用异常处理逻辑集中到一个@ControllerAdvice类里，针对不同异常类型（如BaseException、IllegalArgumentException、IOException）编写对应@ExceptionHandler方法，统一返回标准响应体（如Result）。

• 避免在Service或Controller里手动catch再包装返回，真正实现“一次定义，处处生效”
• 对非业务异常（如空指针、数据库连接失败）也可兜底处理，记录日志并返回友好提示
• 注意异常传播顺序：子类异常处理器优先于父类，需合理安排声明顺序

工具类封装常用校验与抛异常逻辑

把高频校验+抛异常组合抽成静态方法，例如Asserts.notNull(obj, ErrorCode.PARAM_NULL)、Asserts.isTrue(condition, ErrorCode.ILLEGAL_STATE)，内部直接抛出封装好的业务异常。

• 替代冗长的if (xxx == null) { throw new XxxException(...); }
• 校验方法命名清晰（如checkUserExists）、参数明确，调用方语义一目了然
• 不强制要求所有校验都走工具类，但重复出现3次以上的逻辑建议封装

异常链路中避免信息丢失与过度包装

复用异常时，注意保留原始上下文：新抛出的异常应通过cause参数关联原始异常；日志打印时用log.error("xxx", e)而非log.error("xxx" + e)，确保堆栈完整。

• 不要层层catch-throw new XxxException(e)，除非有明确的语义转换（如把DAO层SQLException转为Service层BusinessException）
• 敏感信息（如密码、密钥）不能出现在异常消息中，可在封装时过滤或脱敏
• 对外API返回的错误提示必须友好，错误码可暴露，具体异常类名和堆栈绝不返回给前端

基本上就这些。关键不是少写几行catch，而是让异常成为可读、可控、可追溯的业务信号——封装得当，异常就不再是脏代码，而是系统健壮性的注释。