AOP跨模块捕获异常遭CGLIB拦截而继续向上抛出异常

其他系列文章导航

Java基础合集
数据结构与算法合集

设计模式合集

多线程合集

分布式合集

ES合集

文章目录

其他系列文章导航

文章目录

前言

一、BUG详情

1.1 报错信息

1.2 接口响应信息

1.3 全局异常处理器的定义

二、排查过程

三、解决方案

四、总结

前言

最近，在开发过程中，我遇到一个不易察觉的小bug。这个bug并没有直接给出报错信息，使得排查问题的根源变得困难。我希望通过分享这个经验，帮助大家避免重蹈覆辙，以免浪费不必要的时间和精力。

为了避免类似的困境，我们应当时刻保持警惕，对开发过程中的每一个细节都进行严格的检查。同时，利用调试工具和日志输出等功能，可以帮助我们更快速地定位和解决问题。此外，定期进行代码审查和测试也是非常必要的，这有助于发现潜在的问题并及时解决。

一、BUG详情

1.1 报错信息

如下图所示：

java.lang.reflect.UndeclaredThrowableException: null
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:780) ~[spring-aop-5.3.27.jar:5.3.27]
Caused by: exception.NoAuthorityException: 无权限访问

1.2 接口响应信息

预期是抛出无权限访问异常，但是没有被aop捕获，被上层UndeclaredThrowableException异常捕获。

1.3 全局异常处理器的定义

如下图所示：

@ExceptionHandler(Exception.class)
    public <T> R<T> handle(Exception exception) {
        if (exception instanceof BindException) {
            // Bind错误特殊处理
            return R.wrap(() -> {
                ApiValidationUtil.checkBinding(((BindException) exception).getBindingResult());
                return null;
            });
        }
        return R.errorAndLog(exception);
    }

二、排查过程

找到最上面一层报错，发现错误在CglibAopProxy.class中。

附上源码逻辑：

        @Override
		@Nullable
		public Object proceed() throws Throwable {
			try {
				return super.proceed();
			}
			catch (RuntimeException ex) {
				throw ex;
			}
			catch (Exception ex) {
				if (ReflectionUtils.declaresException(getMethod(), ex.getClass()) ||
						KotlinDetector.isKotlinType(getMethod().getDeclaringClass())) {
					// Propagate original exception if declared on the target method
					// (with callers expecting it). Always propagate it for Kotlin code
					// since checked exceptions do not have to be explicitly declared there.
					throw ex;
				}
				else {
					// Checked exception thrown in the interceptor but not declared on the
					// target method signature -> apply an UndeclaredThrowableException,
					// aligned with standard JDK dynamic proxy behavior.
					throw new UndeclaredThrowableException(ex);
				}
			}
		}

从源码可以看出咱们最后抛出的异常就是UndeclaredThrowableException异常，所以说if块里面的逻辑是false。

继续深挖ReflectionUtils.declaresException(getMethod(), ex.getClass())方法的逻辑。

附上declaresException方法源码：

public static boolean declaresException(Method method, Class<?> exceptionType) {
		Assert.notNull(method, "Method must not be null");
		Class<?>[] declaredExceptions = method.getExceptionTypes();
		for (Class<?> declaredException : declaredExceptions) {
			if (declaredException.isAssignableFrom(exceptionType)) {
				return true;
			}
		}
		return false;
	}

method就是方法体了，exceptionType就是异常类型了。

method.getExceptionTypes()从controller层读到异常类型存入declaredExceptions中，与传入的exceptionType进行判断。

declaredException.isAssignableFrom(exceptionType)的意思是declaredException是不是exceptionType的父类。只要满足捕获的异常是接口抛出异常的父类就行了。

因为原来的controller层接口是并没有声明异常。

如下所示：

    //原先的接口
    @Role(400)
    @Override
    public R<UserInfoVO> getUserInfo(String loginName) {
        Assert.notNull(loginName, "请求参数为空");
        return sysUserInfoService.getUserInfo(loginName);
    }

所以declaredExceptions是空的，那当然返回的是false。

所以走了else的逻辑，向上抛出throw new UndeclaredThrowableException(ex)。

三、解决方案

在接口方法上声明错误类型（exceptionType）。

如下所示：

    @Role(400)
    @Override
    public R<UserInfoVO> getUserInfo(String loginName) throws NoAuthorityException {
        Assert.notNull(loginName, "请求参数为空");
        return sysUserInfoService.getUserInfo(loginName);
    }

这样的话Class<?>[] declaredExceptions = method.getExceptionTypes();可以读到NoAuthorityException 异常，并和拦截到的异常ex.getClass()得到也是NoAuthorityException异常做对比，满足isAssignableFrom方法，所以成功捕获。

由此可见，我们把ex.getClass()，也就是AOP里要捕获的异常设置为Exception也是可以满足需求的。

附一张成功响应图：