# 个人描述测试

## 测试

[百度](https://www.baidu.com)

## 关于框架异常以及业务异常

由于DTAF/TAF框架都是依赖于第三方的框架，在第三方的框架中，他们自定义的异常几乎都是继承自RuntimeException，Java中的运行时异常是不需要进行主动声明抛出的，所以在第三方的框架api中，很少有方法会主动的抛出异常，而我们的TAF框架考虑到了业务代码通常会抛出业务异常，所以定义了TafException，而业务代码在很多时候都需要考虑异常情况，并通过异常抛出的形式给到前端作为提示信息，所以TafException继承自Exception似乎不太合理，这个异常必须显示的声明，所以我们的代码几乎都有声明异常抛出，这一方面带来了注释的维护（维护不彻底打包会有大量的警告信息），另一方面看起来感觉异常声明太泛滥了。所以我觉得应该将TafException继承自RuntimeException。另一方面我们依赖于第三方框架时，在重写方法时，我们只能按照别人的方法定义去实现逻辑，抛出RuntimeException以上或者以外的异常是不允许的。

另外，在client的调用中，应该可以尝试通过openFeign接口定义中提供的异常执行方法key（例如：IPeopleValidityCheckClient#login(String,String)），这是不带有异常声明信息的，但是可以尝试通过key中的类名以及方法名，利用反射机制获取接口的抛出异常，那么就能保留异常类型进行抛出到调用端。但是这好像在同时有多个异常的情况下仍旧不完美，因为存在多个抛出异常时，无法知道响应中的异常信息是哪一种（想通过不同的业务异常类型进行业务判断就变得不可行）。