Spring中如何用@ExceptionHandler处理包装异常及getCause()问题

嘿，这个问题我太熟了！Spring把自定义转换异常包装成ConversionException确实挺闹心的，但有两个优雅的方案能解决，让你不用再反复调用getCause()和instanceof，直接用@ExceptionHandler(MyCustomConversionException.class)处理目标异常。

方案一：全局异常解包（一劳永逸） #

这个方案通过自定义ExceptionHandlerExceptionResolver子类，自动解包所有嵌套的异常，让Spring的异常处理器直接识别最底层的自定义异常。

步骤1：实现自定义异常解析器 #

创建一个解析器类，重写方法来递归获取最底层的异常：

import org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver;
import org.springframework.web.method.HandlerMethod;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.lang.reflect.InvocationTargetException;

public class UnwrappingExceptionHandlerResolver extends ExceptionHandlerExceptionResolver {
    @Override
    protected ModelAndView doResolveHandlerMethodException(
            HttpServletRequest request, 
            HttpServletResponse response, 
            HandlerMethod handlerMethod, 
            Exception exception
    ) {
        // 先处理InvocationTargetException（方法调用时的包装异常）
        Throwable rootCause = exception;
        if (rootCause instanceof InvocationTargetException) {
            rootCause = ((InvocationTargetException) rootCause).getTargetException();
        }
        // 递归获取最底层的异常
        while (rootCause.getCause() != null && rootCause.getCause() != rootCause) {
            rootCause = rootCause.getCause();
        }
        // 用解包后的异常调用父类的处理逻辑
        return super.doResolveHandlerMethodException(request, response, handlerMethod, (Exception) rootCause);
    }
}

步骤2：注册解析器到Spring容器 #

在配置类里把这个解析器注册为Bean：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class WebConfig {
    @Bean
    public UnwrappingExceptionHandlerResolver unwrappingExceptionHandlerResolver() {
        return new UnwrappingExceptionHandlerResolver();
    }
}

步骤3：直接处理自定义异常 #

现在你可以在全局异常处理器里直接写针对自定义异常的处理方法，完全不用管ConversionException：

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(MyCustomConversionException.class)
    public ResponseEntity<ErrorResponse> handleCustomConversionException(MyCustomConversionException ex) {
        ErrorResponse error = new ErrorResponse(
                HttpStatus.BAD_REQUEST.value(),
                "参数格式错误：" + ex.getMessage()
        );
        return new ResponseEntity<>(error, HttpStatus.BAD_REQUEST);
    }

    // 其他异常处理方法...
}

这个方案的好处是一劳永逸，以后任何被Spring包装的异常（不止ConversionException）都会被自动解包，你的异常处理器可以直接针对底层异常写逻辑。

方案二：针对ConversionException局部解包（灵活可控） #

如果你只需要处理ConversionException的包装场景，不想全局修改异常解析逻辑，可以在全局处理器里统一解包ConversionException，再转发到对应处理方法。

实现代码 #

@ControllerAdvice
public class GlobalExceptionHandler {
    // 处理ConversionException，先解包再转发
    @ExceptionHandler(ConversionException.class)
    public ResponseEntity<?> handleConversionException(ConversionException ex) {
        Throwable rootCause = getRootCause(ex);
        if (rootCause instanceof MyCustomConversionException) {
            return handleCustomConversionException((MyCustomConversionException) rootCause);
        } else {
            // 处理其他未预期的转换异常
            ErrorResponse error = new ErrorResponse(
                    HttpStatus.INTERNAL_SERVER_ERROR.value(),
                    "参数转换失败：" + rootCause.getMessage()
            );
            return new ResponseEntity<>(error, HttpStatus.INTERNAL_SERVER_ERROR);
        }
    }

    // 直接处理自定义转换异常
    @ExceptionHandler(MyCustomConversionException.class)
    public ResponseEntity<ErrorResponse> handleCustomConversionException(MyCustomConversionException ex) {
        ErrorResponse error = new ErrorResponse(
                HttpStatus.BAD_REQUEST.value(),
                "参数格式错误：" + ex.getMessage()
        );
        return new ResponseEntity<>(error, HttpStatus.BAD_REQUEST);
    }

    // 工具方法：递归获取最底层异常
    private Throwable getRootCause(Throwable throwable) {
        Throwable cause;
        while ((cause = throwable.getCause()) != null && cause != throwable) {
            throwable = cause;
        }
        return throwable;
    }
}

这个方案更灵活，你可以精准控制哪些包装异常需要解包，适合只需要处理特定场景的情况。

为什么重新抛出原异常会报错？ #

你提到的Failed to invoke @ExceptionHandler method日志，是因为Spring在调用@ExceptionHandler方法时，已经进入了异常处理的上下文流程。如果在方法里重新抛出异常，Spring会认为这个处理器处理失败，从而打印错误日志，还可能触发默认的异常处理机制，确实不太友好。上面的两个方案都避免了这个问题。

内容的提问来源于stack exchange，提问作者HughWPHamill