作者：才女我是周宇 | 来源：互联网 | 2023-09-07 11:43
篇首语：本文由编程笔记#小编为大家整理，主要介绍了使用DubboJSF等RPC框架时，对于异常的处理相关的知识，希望对你有一定的参考价值。
无论是Dubbo还是JSF等RPC框架，一般都会把接口分为2部分：
1，服务端（provider）
2，客户端（consumer）
由于，客户端与服务端可能不在同一个应用中，所以客户端一般在调用服务端的接口时，通常会返回一个结果实体，来标明这一次请求操作是否成功。
例如：
public class BaseResultDto {
/**
* 是否操作成功
*/
private boolean success;
/**
* 提示信息
*/
private String msg;
/**
* 操作结果
*/
private T result;
}
客户端在拿到这个实体后，可以明确得知，这一次操作是否成功。
但是防御式编程中，我们应该对一切未知的接口都持有怀疑态度，况且不怕一万就怕万一：“如果服务端出现异常怎么办？”
网上有2中答案：
1，直接将异常抛出去，经过RPC序列化后，客户端进行展示。
2，不抛异常出去，服务端进行全方位拦截，拦截到后，通过BaseResultDto，告诉客户端现在服务端出现异常了。
但是各自的缺点很明显：
1，服务端与客户端，很可能不在同一个应用中，所以各自会依赖不同的jar包，比方说：服务端抛出了个spring的duplicateKeyException，但是客户端并没用引用spring的相关jar包，这样就会导致：抛出异常后，由于客户端没有依赖这个类，最终抛出个ClassNotDefError，注意是Error不是Exception。如果客户端只对Exception进行捕获的话，会导致直接抛到最顶层。可能日志、重试等都没了。
2，全方位拦截后，可能返回的结果中只会告诉客户端：“系统出现异常”,无法准确通过日志去定位问题。
最终解决方案：
将2者折中处理，服务端全方位进行拦截，如果出现异常后，把异常信息转换成字符串，然后把异常信息返回到客户端中：
public class BaseResultDto {
/**
* 是否操作成功
*/
private boolean success;
/**
* 提示信息
*/
private String msg;
/**
* 操作结果
*/
private T result;
/**
* 异常堆栈信息
*/
private String errorTrace;
}
errorTrace就是存储异常对战信息的属性，这样如果客户端检测到success为false，这样就可以直接把errorTrace打到log中，方便定位问题。
京公网安备 11010802041100号