dubbo自动转换异常类型的坑

大家都知道&＃xff0c;大部分企业都会有自己的自定义异常。

在某种特殊情况下&＃xff0c;dubbo会将自定义异常转换为RuntimeException&＃xff0c;例如&＃xff1a;

我在dubbo-provider-service-impl里自定义一个异常TestException

public class TestException extends RuntimeException{private static final long serialVersionUID &＃61; 2663095676298579664L;private String message;public TestException() {}public TestException(Exception e) {super(e.getMessage(), e instanceof TestException ? (TestException)e : e);this.message &＃61; e.getMessage();}public TestException(TestException te) {super(te.getMessage(),te);this.message &＃61; te.getMessage();}public TestException(String msg){super(msg);this.message &＃61; msg;}public String getMessage(){String result;if(this.message &＃61;&＃61; null || "".equals(this.message)){result &＃61; super.getMessage();}else{result &＃61; this.message;}return result;}}


接着&＃xff0c;在dubbo-provider-service里定义TestService

public interface TestService {public void test();}


然后在dubbo-provider-service-impl中定义TestServiceImpl

&＃64;Service("testService")
public class TestServiceImpl implements TestService{&＃64;Overridepublic void test() {throw new TestException("this is TestException...");}}


创建一个dubbo消费者工程

注&＃xff1a;dubbo中Testservice相关的配置省略

在dubbo-consumer中新建TestController

&＃64;RestController
&＃64;RequestMapping("/test")
public class TestController {&＃64;Resource(name &＃61; "testService")private TestService testService;&＃64;RequestMapping("/test")public String test() {try {testService.test();} catch (Exception e) {System.out.println(">>>>>>>>>>" &＃43; e.getClass());e.printStackTrace();}return "SUCCESS";}}


启动这两个工程&＃xff0c;访问dubbo-consumer中TestController的test方法&＃xff0c;你就会发现控制台打印如下信息

注意&＃xff0c;控制台中打印了“>>>>>>>>>>class java.lang.RuntimeException”

明明生产者中抛出的异常类型是TestException&＃xff0c;怎么到了消费者中变成了RuntimeException呢

别急&＃xff0c;我们先找下错误信息&＃xff0c;往下拉&＃xff0c;你会发现

就是这里对自定义异常进行了转换

就是这个invoke方法&＃xff0c;我们来看一下它的注释

1.“directly throw if it’s checked exception”&＃xff1a;意思就是说&＃xff0c;如果该异常是检查型异常&＃xff0c;则直接抛出

2.“directly throw if the exception appears in the signature”&＃xff1a;大概意思是&＃xff0c;如果接口的方法声明中抛出了该异常&＃xff0c;则直接抛出

3.“for the exception not found in method’s signature, print ERROR message in server’s log”&＃xff1a;意思是&＃xff0c;如果接口的方法中没有声明该异常&＃xff0c;则打印ERROR日志

4.“directly throw if exception class and interface class are in the same jar file”&＃xff1a;大概意思是&＃xff1a;如果异常类和接口类在同一个jar中&＃xff0c;则直接抛出

5.“directly throw if it’s JDK exception”&＃xff1a;意思是&＃xff0c;如果是JDK中的异常&＃xff0c;则直接抛出

6.“directly throw if it’s dubbo exception”&＃xff1a;如果是dubbo的异常&＃xff0c;则直接抛出

7.“otherwise, wrap with RuntimeException and throw back to the client”&＃xff1a;否则&＃xff0c;包装成RuntimeException抛出给客户端

根据错误信息同时结合注释&＃xff0c;我们知道是走了7&＃xff0c;你可能会觉得很坑&＃xff0c;但仔细想一下&＃xff0c;他这样做是很有必要的&＃xff0c;因为走了第七步说明生产者定义的异常类在消费者上是找不到的&＃xff0c;这时如果不把它包装成RuntimeException&＃xff0c;那么在反序列化时就会出现问题&＃xff0c;会无法序列化。

所以&＃xff0c;最好的办法是&＃xff1a;将异常类定义在公共的jar包中&＃xff0c;然后生产者和消费者都引用它&＃xff0c;同时生产者的接口声明中抛出该异常。