Spring 的 @ExceptionHandler 方法不可再抛出异常，否则会触发二次异常处理流程，导致类加载失败、代理类找不到等 ClassNotFoundException；正确做法是直接返回统一错误响应体。
spring 的 `@exceptionhandler` 方法不可再抛出异常，否则会触发二次异常处理流程，导致类加载失败、代理类找不到等 `classnotfoundexception`；正确做法是直接返回统一错误响应体。
在 Spring Web 应用中，@ControllerAdvice 配合 @ExceptionHandler 是实现全局异常统一处理的标准方案。但一个常见误区是：在 @ExceptionHandler 方法内部再次 throw new XxxException()——这不仅违背设计初衷，还会引发严重问题，正如你遇到的 ClassNotFoundException（如 com.sun.proxy.$Proxy205、ServiceImpl$$EnhancerBySpringCGLIB$$xxx 等动态代理类无法加载）。
为什么不能在 @ExceptionHandler 中抛出异常？
Spring 的异常处理机制由 ExceptionHandlerExceptionResolver 负责执行。当控制器方法抛出 SQLException 后，Spring 会定位到你的 @ExceptionHandler(SQLException.class) 方法并调用它。但该方法本身若再抛出 ServiceException，Spring 会将其视为“异常处理器执行失败”，进而尝试启动默认错误页（如 /error）或交由其他 HandlerExceptionResolver 处理。此时，Spring Boot 内置的 BasicErrorController 会尝试解析原始异常链（包括被代理的 Service 类、Mapper 接口等），而这些 CGLIB 或 JDK 动态生成的代理类在错误上下文中可能尚未被 ClassLoader 正确加载或已被卸载，最终抛出 ClassNotFoundException。
简言之：@ExceptionHandler 是异常处理的终点，不是中转站；它必须“消化”异常，而非转发。
正确写法：返回标准响应体
应将业务异常信息封装为 JSON 响应，而非抛出：
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
@Log4j2
@ControllerAdvice
public class GlobalSQLExceptionHandler {
@ExceptionHandler(value = SQLException.class)
@ResponseBody
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) // 显式设为 500
public Result> sqlExceptionHandler(HttpServletRequest req, SQLException e) {
log.error("数据库操作异常 [URL:{}]", req.getRequestURL(), e);
// 返回统一响应结构（假设 Result 是项目约定的泛型响应类）
return Result.fail("系统繁忙，请稍后重试");
}
}
✅ 关键点说明：
-
返回值类型：推荐使用
Result>、Map<string object></string>或自定义响应实体，避免void； -
@ResponseStatus：显式指定 HTTP 状态码（如500 INTERNAL_SERVER_ERROR），确保前端可准确识别错误级别； -
日志记录：务必使用
log.error(String, Throwable)形式，保留完整堆栈，便于排查； -
敏感信息过滤：
e.getMessage()可能含数据库名、表名等，生产环境建议脱敏或仅记录内部日志，响应体中使用通用提示。
进阶建议：分层异常处理策略
| 异常类型 | 处理方式 | 示例 |
|---|---|---|
SQLException / DataAccessException
|
全局拦截 → 返回 500 + 通用提示 |
如上代码 |
自定义业务异常（如 ServiceException） |
单独 @ExceptionHandler → 返回 400/409 等语义化状态码 |
@ExceptionHandler(ServiceException.class) |
ValidationException |
拦截 MethodArgumentNotValidException → 提取校验错误字段 |
返回 400 + 字段级错误信息 |
注意事项总结
- ❌ 禁止在任何
@ExceptionHandler方法中使用throw new XxxException()； - ✅ 所有异常处理逻辑必须以 返回值（非空响应体）结束；
- ? 生产环境切勿将原始异常消息（尤其是
SQLException）直接返回给前端； - ? 若需触发下游统一错误日志/告警，应在
@ExceptionHandler方法内主动调用日志服务或事件发布器，而非依赖异常传播； - ? 确保
Result类已正确配置序列化（如使用 Jackson），避免因响应体序列化失败引发二次异常。
遵循以上规范，即可安全、稳定地实现 SQL 异常的全局拦截与友好降级，彻底规避 ClassNotFoundException 及其背后复杂的类加载陷阱。
