前言

我们在开发应用系统时，不可避免的要使用到我们自己定义的异常，所以我们一般通常会用到自定义的业务异常类BusinessException，这个异常会继承extends RuntimeException，当发生业务限制的时候，会throw出来。

问题

在SpringMVC项目中，我们可以采用@ControllerAdvice注解，拦截我们的业务异常类，然后做一些处理。

网上有很多SpringMVC项目如何统一处理异常。老顾这里就不做介绍

但是现在项目都是微服务化的，在使用dubbo构建项目时，会发现provider抛出自定义业务异常，在custom端并不能正确的捕获。即便我们在provider和custom都有导入相同jar包下面的BusinessException异常，并且抛出这个异常。下面是出错情况

老顾采用dubbo版本为2.7.3版本，跟老版本有点区别，但区别不大

provicer生产者代码

其中的DataNotFoundException继承了BusinessException

DataNotFoundException 的编码以及错误信息： PUBLIC_DATA_NOT_FOUND(1001,"数据没有找到") 

consumer消费者代码

运行，输入不存在的goodsID，我们期望我们自定义的异常类被我们拦截到，并做一些处理；但是provider生产端抛给消费者的异常竟然是RuntimeException，只是里面的message是我们的业务异常调用栈信息。如下：

不是我们希望的抛给消费者端是DataNotFoundException异常。导致我们消费端没法针对不同的业务进行不同的处理。消费端做了SpringMVC的异常处理返回了：

上面的code为1401，是系统异常编码，并不是DataNotFoundException编码。

我们定义的DataNotFoundException的编码为：1001

为什么产生

我们来看看dubbo的源码进行分析，如果Dubbo的 provider端 抛出异常(Throwable)，则会被 provider端 的ExceptionFilter拦截到，执行以下invoke方法，里面有个实现Listener类，重写了onResponse。

我们来分析一些代码：

if  (appResponse.hasException() &&  GenericService.class    != invoker.getInterface())

上面代码的含义就是 如果有异常并且未实现GenericService接口，进入后续判断逻辑，否则直接返回结果。

上面代码的含义就是 不是RuntimeException类型的异常，并且是受检异常(继承Exception)，直接抛出。

上面代码的含义就是 在方法签名上有声明，直接抛出。

上面代码的含义就是 如果异常类和接口类在同一个jar包中，直接抛出。

上面代码的含义就是 以java.或javax.开头的异常直接抛出。

上面代码的含义就是dubbo自身的异常，直接抛出。

不满足上述条件，会做toString处理并被封装成RuntimeException抛出。

现在我们知道了 为什么我们自定义的异常，没有正确的抛出，这个是因为上面的几个条件，我们都没有满足，所以最后dubbo把它封装成了RuntimeException。

如何解决

解决方法就针对上面的几个条件进行，有几种方案，我们一一看一下：

1、将该异常的包名以java.或者javax.开头

这个方案不现实，也不符合规范，所以不采用

2、业务异常继承Exception，变为checked异常

自定义的业务异常本身属于RuntimeException，所以也不采用

3、异常类和接口类在同一jar包里

较大的项目一般都会有一些common包，定义好异常类型，使用二方包的方式引用，所以也不适用

4、provider的api明确写明throws XxxException

作为生产服务端，不应显式抛出异常给客户的进行处理，所以也不适用

最终方案

以上方案都不合适，我们这里介绍个最终的方案，即采用dubbo的filter重写，dubbo的异常处理。

1、将dubbo源码中ExceptionFilter复制到我们的项目改名为DubboExceptionFilter修改一些代码

2、在此处加上一段代码来过滤我们项目中的异常，以免被dubbo重新封装3、在resources目录下添加纯文本文件META-INF/dubbo/com.alibaba.dubbo.rpc.Filter并添加内容

dubboExceptionFilter=com.rainbow.goods.server.filter.DubboExceptionFilter

4、修改dubbo 的配置文件，将DubboExceptionFilter加载进去并且去掉自身的ExceptionFilter

上面exception就是dubbo默认的处理异常的filter，前面-号就代表去除

我们修改后，再运行：

抛出的是我们自定义的异常了，在看看消费端的异常处理最终显示

确实是我们定义的DataNotFoundException业务异常的编码和信息。

总结

上面的是基于重写dubbo的filter处理了异常，网上有一些别的方案，老顾认为不是太合理，不够灵活，利用修改dubbo源码的方式解决更能彻底解决；希望能够给小伙伴带来帮助。谢谢！！！