dubbo异常处理

      dubbo有自己的异常处理机制，当服务端抛出一个dubbo可以处理传递的异常时，会直接在客户端上再次抛出，由开发者自己去处理。注意：这里说的不是所有异常，而是dubbo可以处理传递的异常，具体这个后边再说。

     先看两段代码，接口代码：

     

public interface IPersonService {
    public Person getPerson(long id);
    /**
     * 根据名称获取
     *
     * @param name
     * @return
     */
    public Person getByNick(String name);
}

      简单实现：

 

    

public class PersonServiceImpl implements IPersonService {
    private final static AtomicInteger ID = new AtomicInteger();

    @Override
    public Person getPerson(long id) {
        Person person = new Person();
        person.setId(id);
        person.setName("某某");
        try {
            Thread.sleep(2000l);
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        return person;
    }

    @Override
    public Person getByNick(String name) {
        name = name.trim();
        Person person = new Person();
        person.setId(ID.getAndIncrement());
        person.setName(name);
        return person;
    }

}

        这两段代码很简答，先看getByNick方法，根据用户名称获取用户信息，里面有一个去空格的操作（主要为了触发异常），正常调用是没有问题的，但如果传入null，就会抛出很常见且低级的空指针异常。我们看下调用代码：

 

   

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
                new String[] { "app-dubbo-consumer.xml" });
        context.start();
        IPersonService personService = context.getBean(IPersonService.class);
        // 正常输入参数
        outString(personService.getByNick("某某"));
        // 输入null
        outString(personService.getByNick(null));

     运行后，首先会打印{"id":0,"name":"某某"}，然后出现java.lang.NullPointerException，一切在我们的预料内，dubbo把服务端的空指针异常传递给客户端了。

 

     正常来说，空指针异常是不应该出现的，而且客户端遇到这个错误肯定直接懵了，所以我们做下简单的修改，服务端代码：

  

@Override
    public Person getByNick(String name) {
        if (name == null) {
            throw new RuntimeException("亲你咋没输入昵称呢");
        }
        name = name.trim();
        Person person = new Person();
        person.setId(ID.getAndIncrement());
        person.setName(name);
        return person;
    }

         客户端再次调用结果：

 

  

Exception in thread "main" java.lang.RuntimeException: 亲你咋没输入昵称呢
    at org.dubbo.provider.PersonServiceImpl.getByNick(PersonServiceImpl.java:28)
    at com.alibaba.dubbo.common.bytecode.Wrapper1.invokeMethod(Wrapper1.java)

     结果友好了多，甚至你可以直接对exception获取异常信息作为输出。

 

       上边提到过当服务端抛出一个dubbo可以处理传递的异常时，会直接在客户端上再次抛出，但不是所有的异常都是dubbo可以处理传递的，如下边的代码：

   

@Override
    public Person getByNick(String name) {
        if (name == null) {
            // 第三方异常
            throw new PersistenceException("mybatis插入异常");
        }
        name = name.trim();
        Person person = new Person();
        person.setId(ID.getAndIncrement());
        person.setName(name);
        return person;
    }

 

        这里我们模拟抛出了一个mybatis的异常，在客户端调用会像上边的结果一样吗？答案是否定的，看下输出结果：

 

Exception in thread "main" java.lang.RuntimeException: org.apache.ibatis.exceptions.PersistenceException: mybatis插入异常
org.apache.ibatis.exceptions.PersistenceException: mybatis插入异常
    at org.dubbo.provider.PersonServiceImpl.getByNick(PersonServiceImpl.java:32)
    at com.alibaba.dubbo.common.bytecode.Wrapper1.invokeMethod(Wrapper1.java)

       不要感觉奇怪，这个也是在可以接受的范围内，因为PersistenceException异常类在客户端是不存在的，所以不可能接收到PersistenceException异常，dubbo把他进行了封装。

 

        针对这点，在接口包中里面定义了一个全局的异常类，注意一定是接口所在的工程中，如：UicException（用户模块异常），这种方案也是官方建议的，服务端代码如下：

  

@Override
    public Person getByNick(String name) {
        if (name == null) {
            // 自定义异常
            throw new UicException("mybatis插入异常", 0);
        }
        name = name.trim();
        Person person = new Person();
        person.setId(ID.getAndIncrement());
        person.setName(name);
        return person;
    }

 

           错误信息如下

 

Exception in thread "main" org.dubbo.api.exception.UicException: mybatis插入异常
    at org.dubbo.provider.PersonServiceImpl.getByNick(PersonServiceImpl.java:30)

         这个正是我们想要的异常信息，上边特别提到异常一定要在接口所在的工程中，如果异常类不在接口工程中，而是在另一个服务端和客户端都引入的包中呢？我们曾经碰到这样一个情况，有一个common的异常类放在一个很底层的工具包内，接口工程引入了这个包，在服务端抛出的异常都都是这个commonexception，一厢情愿的认为客户端会正常去捕获处理commonexception。

 

         但结果很意外，客户端出现的异常跟上边抛出的PersistenceException情况一样，dubbo用RuntimException进行了包装，我们无法从异常中获取有效的信息！遇到这种情况有点发懵，这个异常类在客户端和服务端都有呀，为啥不能正确接收呢。还好之前看dubbo源码的时候大概记得异常处理的位置，很好找到了目标代码：

 

if (result.hasException() && GenericService.class != invoker.getInterface()) {
               try {
                   Throwable exception = result.getException();

                   // 如果是checked异常，直接抛出
                   if (! (exception instanceof RuntimeException) && (exception instanceof Exception)) {
                       return result;
                   }
                   // 在方法签名上有声明，直接抛出
                   try {
                       Method method = invoker.getInterface().getMethod(invocation.getMethodName(), invocation.getParameterTypes());
                       Class<?>[] exceptionClassses = method.getExceptionTypes();
                       for (Class<?> exceptionClass : exceptionClassses) {
                           if (exception.getClass().equals(exceptionClass)) {
                               return result;
                           }
                       }
                   } catch (NoSuchMethodException e) {
                       return result;
                   }

                   // 未在方法签名上定义的异常，在服务器端打印ERROR日志
                   logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost()
                           + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()
                           + ", exception: " + exception.getClass().getName() + ": " + exception.getMessage(), exception);

                   // 异常类和接口类在同一jar包里，直接抛出
                   String serviceFile = ReflectUtils.getCodeBase(invoker.getInterface());
                   String exceptionFile = ReflectUtils.getCodeBase(exception.getClass());
                   if (serviceFile == null || exceptionFile == null || serviceFile.equals(exceptionFile)){
                       return result;
                   }
                   // 是JDK自带的异常，直接抛出
                   String className = exception.getClass().getName();
                   if (className.startsWith("java.") || className.startsWith("javax.")) {
                       return result;
                   }
                   // 是Dubbo本身的异常，直接抛出
                   if (exception instanceof RpcException) {
                       return result;
                   }

                   // 否则，包装成RuntimeException抛给客户端
                   return new RpcResult(new RuntimeException(StringUtils.toString(exception)));
               } catch (Throwable e) {
                   logger.warn("Fail to ExceptionFilter when called by " + RpcContext.getContext().getRemoteHost()
                           + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()
                           + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
                   return result;
               }
           }

          看完源码以后，做出了新的设计，CommonException不变，各个接口模块（maven工程为单位）单独定义异常对象继承CommonException(保证异常类和接口在同一模块，然后用里氏代换)，每个模块抛出自己的模块异常（如用户模块抛出UicException），客户端中用CommonException统一捕获处理。

 

          这里还要定义两个拦截器，首先是服务端，保证所有抛出的异常是当前模块的异常，代码如下：

 

public class UICExceptionAspect {
    private static Log log = LogFactory.getLog(UICExceptionAspect.class);

    public void afterThrowing(Exception ex) {

        if (ex instanceof UICException) {
            throw (UICException) ex;
        } else if (ex instanceof DayimaException) {
            DayimaException de = (DayimaException) ex;
            throw new UICException(de.getErrCode(), de.getErrMsg());
        } else {
            log.error(ex.getMessage(), ex);
            throw new UICException("1", ex.getMessage());
        }

    }
}

         其次是客户端的，保证异常可以正确的友好的输出，所有CommonException可以直接输出（获取根据错误码获取错误信息），非CommonException异常根据自己需要去处理，如果是dubbo自带异常肯定要屏蔽异常信息，如打印日志后输出“网络异常”。

 

       还有另一种dubbo调用方案，普通service层外边嵌套一层用来做dubbo的服务，普通service层处理了事务之类，dubbo服务层每一个方法都是客户端要引用的，直接调用普通service层方法，但做了手动的try catch处理，封装自己的返回码，客户端只需要根据返回码去做处理，这种开发成本和文档成本有点高，没太深入去考虑。

        以上是我自己工作中的dubbo异常实践，以后会继续写些其他的心得，记录自己的成长。