背景
在RPC接口调用场景或者使用动态代理的场景中,偶尔会出现UndeclaredThrowableException,又或者在使用反射的场景中,出现InvocationTargetException,这都与我们所期望的异常不一致,且将真实的异常信息隐藏在更深一层的堆栈中。本文将重点分析下UndeclaredThrowableException
先给结论
使用jdk动态代理接口时,若方法执行过程中抛出了受检异常但方法签名又没有声明该异常时则会被代理类包装成UndeclaredThrowableException抛出。
问题还原
// 接口定义 public interface IService { void foo() throws SQLException; } public class ServiceImpl implements IService{ @Override public void foo() throws SQLException { throw new SQLException("I test throw an checked Exception"); } } // 动态代理 public class IServiceProxy implements InvocationHandler { private Object target; IServiceProxy(Object target){ this.target = target; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(target, args); } } public class MainTest { public static void main(String[] args) { IService service = new ServiceImpl(); IService serviceProxy = (IService) Proxy.newProxyInstance(service.getClass().getClassLoader(), service.getClass().getInterfaces(), new IServiceProxy(service)); try { serviceProxy.foo(); } catch (Exception e){ e.printStackTrace(); } } }
运行上面的MainTest,得到的异常堆栈为
java.lang.reflect.UndeclaredThrowableException at com.sun.proxy.$Proxy0.foo(Unknown Source) at com.learn.reflect.MainTest.main(MainTest.java:16) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.learn.reflect.IServiceProxy.invoke(IServiceProxy.java:19) ... 2 more Caused by: java.sql.SQLException: I test throw an checked Exception at com.learn.reflect.ServiceImpl.foo(ServiceImpl.java:11) ... 7 more
而我们期望的是
java.sql.SQLException: I test throw an checked Exception at com.learn.reflect.ServiceImpl.foo(ServiceImpl.java:11) ...
原因分析
在上述问题还原中,真实的SQLException被包装了两层,先被InvocationTargetException包装,再被UndeclaredThrowableException包装。 其中,InvocationTargetException为受检异常,UndeclaredThrowableException为运行时异常。 为何会被包装呢,还要从动态代理的生成的代理类说起。
jdk动态代理会在运行时生成委托接口的具体实现类,我们通过ProxyGenerator手动生成下class文件,再利用idea解析class文件得到具体代理类: 截取部分:
public final class IServiceProxy$1 extends Proxy implements IService { private static Method m1; private static Method m2; private static Method m3; private static Method m0; public IServiceProxy$1(InvocationHandler var1) throws { super(var1); } public final void foo() throws SQLException { try { super.h.invoke(this, m3, (Object[])null); } catch (RuntimeException | SQLException | Error var2) { throw var2; } catch (Throwable var3) { throw new UndeclaredThrowableException(var3); } } static { try { m1 = Class.forName("java.lang.Object").getMethod("equals", new Class[]{Class.forName("java.lang.Object")}); m2 = Class.forName("java.lang.Object").getMethod("toString", new Class[0]); m3 = Class.forName("com.learn.reflect.IService").getMethod("foo", new Class[0]); m0 = Class.forName("java.lang.Object").getMethod("hashCode", new Class[0]); } catch (NoSuchMethodException var2) { throw new NoSuchMethodError(var2.getMessage()); } catch (ClassNotFoundException var3) { throw new NoClassDefFoundError(var3.getMessage()); } } }
在调用“委托类”的foo方法时,实际上调用的代理类IServiceProxy$1的foo方法,而代理类主要逻辑是调用InvocationHandler的invoke方法。 异常处理的逻辑是,对RuntimeException、接口已声明的异常、Error直接抛出,其他异常被包装成UndeclaredThrowableException抛出。 到这里,或许你已经get了,或许你有疑问,在接口实现中的确是throw new SQLException,为什么还会被包装呢? 再来看IServiceProxy的invoke方法,它就是直接通过反射执行目标方法,问题就在这里了。 Method.invoke(Object obj, Object... args)方法声明中已解释到,若目标方法抛出了异常,会被包装成InvocationTargetException。(具体可查看javadoc)
所以,串起来总结就是: 具体方法实现中抛出SQLException被反射包装为会被包装成InvocationTargetException,这是个受检异常,而代理类在处理异常时发现该html" target="_blank">异常在接口中没有声明,所以包装为UndeclaredThrowableException。
解决方法
在实现InvocationHandler的invoke方法体中,对method.invoke(target, args);调用进行try catch,重新 throw InvocationTargetException的cause。即:
@Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try { return method.invoke(target, args); } catch (InvocationTargetException e){ throw e.getCause(); } }
题外话
为什么代理类中对未声明的受检异常转为UndeclaredThrowableException? 因为Java继承原则:即子类覆盖父类或实现父接口的方法时,抛出的异常必须在原方法支持的异常列表之内。 代理类实现了父接口或覆盖父类方法
参考
https://www.ibm.com/developerworks/cn/java/j-lo-proxy1/index.html#icomments
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对小牛知识库的支持。
前言 在 gRPC 的新版本(1.0.0-pre2)中,为了方便传递 debug 信息,在 StatusException 和 StatusRuntimeException 中增加了名为 Trailer 的 Metadata。 注: 在此之前,Status(和Status映射的StatusException)只有两个字段可以传递信息:1. status code 2. status decript
本文向大家介绍详解java JDK 动态代理类分析(java.lang.reflect.Proxy),包括了详解java JDK 动态代理类分析(java.lang.reflect.Proxy)的使用技巧和注意事项,需要的朋友参考一下 详解java JDK 动态代理类分析(java.lang.reflect.Proxy)
本文向大家介绍Java 动态代理原理分析,包括了Java 动态代理原理分析的使用技巧和注意事项,需要的朋友参考一下 Java 动态代理原理分析 概要 AOP的拦截功能是由java中的动态代理来实现的。说白了,就是在目标类的基础上增加切面逻辑,生成增强的目标类(该切面逻辑或者在目标类函数执行之前,或者目标类函数执行之后,或者在目标类函数抛出异常时候执行。Spring中的动态代理是使用Cglib进行实
本文向大家介绍浅谈Java代理(jdk静态代理、动态代理和cglib动态代理),包括了浅谈Java代理(jdk静态代理、动态代理和cglib动态代理)的使用技巧和注意事项,需要的朋友参考一下 一、代理是Java常用的设计模式,代理类通过调用被代理类的相关方法,并对相关方法进行增强。加入一些非业务性代码,比如事务、日志、报警发邮件等操作。 二、jdk静态代理 1、业务接口 2、业务实现类 3、代理类
本文向大家介绍Java动态代理静态代理实例分析,包括了Java动态代理静态代理实例分析的使用技巧和注意事项,需要的朋友参考一下 代理模式:为其他对象提供一种代理以控制某个对象的访问。用在:在某些情况下,一个客户不想或者不能直接访问另一个对象,而代理对象可以在客户端和目标对象之前起到中介的作用,代理对象还可以完成它附加的操作。 例子:就像房东、租客、中介的关系。中介(代理对象)为房东(真实对象)出租
本文向大家介绍Java异常处理实例分析,包括了Java异常处理实例分析的使用技巧和注意事项,需要的朋友参考一下 本文实例讲述了Java异常处理的用法。分享给大家供大家参考。具体分析如下: Java的异常处理机制可以帮助我们避开或者处理程序可能发生的错误,从而使得程序在遇到一些可恢复的错误的时候不会意外终止,而是去处理这些错误,也使得我们在写程序的时候不必写大量的代码来检查错误情况,增强了代码的可读