异常处理

• 处理控制异常：这类异常通常是框架处理流程上的异常。比如流控Handler抛出TOO_MANY_REQUESTS_STATUS异常。

java CommonExceptionData errorData = new CommonExceptionData(cause.getMessage()); asyncResp.producerFail(new InvocationException(590, errorData) 或者 java asyncResp.consumerFail(new InvocationException(490, errorData)

通常业务在开发服务代码的时候，只有一个返回值，但有些情况，也需要视具体情况返回不同的消息。可以通过@ApiResonse来定义不同错误码对应的返回消息。业务异常具备确定的数据类型，并且会在swagger里面体现，客户端代码在处理异常的时候，能够直接获取到错误类型。比如下面的代码：

控制异常一般在接口定义里面没有声明。客户端在做异常处理的时候，不知道异常类型。可以采用弱类型的方式处理异常：

上面的代码假设不知道异常类型，通过API将异常类型转换为Map类型，然后从Map里面读取异常类型。在ServiceComb自己抛出的异常类型中，一般控制异常的类型也是固定的，为CommonExceptionData。

未知异常统一被封装为490， 590错误码，异常消息的类型固定为CommonExceptionData类型。

• 控制消息消息体序列化

控制消息消息体序列化的目的是简化消费者的异常处理逻辑，不用使用弱类型，而是使用确切类型。可以采用注册全局的错误码类型。 业务需要通过SPI实现org.apache.servicecomb.swagger.invocation.response.ResponseMetaMapper接口。接口的核心内容是为每个错误码制定序列化类型： ```java private final static Map CODES = new HashMap<>(1);

```

• 异常转换

如果业务不对异常进行转换，ServiceComb会将InvocationException中的data直接序列化到响应消息中。如果不是InvocationException，则转换为490， 590，序列化的消息为CommonExceptionData。业务可以通过SPI实现org.apache.servicecomb.swagger.invocation.exception.ExceptionToProducerResponseConverter对异常进行转换。的说明如下： - getExceptionClass()方法会返回converter实现类所处理的异常类型。如果该方法返回null，则说明此实现类为默认converter。 - Response convert(SwaggerInvocation swaggerInvocation, T e)方法中实现处理异常的逻辑，该方法返回的决定了ServiceComb将会返回何种状态码、何种response body的应答。 - getOrder()方法用以确定converter实现类的优先级，该方法返回的值越小，优先级越高，如果不覆写该方法的话，则返回默认优先级0。对于处理同一异常类型的converter（或默认converter），只有优先级最高的生效。 - 在为异常选择converter时，会从异常本身的类型开始匹配，如果找不到对应的converter则逐级向上查找父类型的converter。当匹配到Throwable仍未找到converter时，将使用默认converter处理异常。

} ```