异常与错误码

异常实践
1.异常捕获处理
try：

代码块粒度尽量小
catch：

获具体异常以缩小关注点；
记录log得体现有价值的业务信息、且不丢失原始异常栈信息；
最外层捕获处理，避免到处记录混淆来源；
尽量使用jdk自带的异常，自定义异常类应该提供有价值的信息；
finally：

处理释放资源
避免在finally中抛出异常（造成try中异常调用栈信息丢失）;
2.服务提供方抛出checked还是unchecked(RuntimeException)
从服务提供方的角度看

期望调用方关注并进行潜在容错（如重试、降级）则抛出checked；

期望直接中断程序（一般是基础性严重问题，及时调用方及时捕获了，也只能rethrow或者中断程序）则抛出unchecked

ps：项目内建议定义unchecked类型的业务异常（XxxBizException extends RuntimeException)；

3.服务调用方catch异常后，是否应该重新抛出throw/throws
建议控制异常的边界，如SqlException(checked)，应该限定在dao层，避免污染上游。

e.g. spring orm将大部分 JDBC checked Exception 都被包装进 DataAccessException （unchecked）;

4.返回Result模型还是直接抛出异常
对于Manager/Service层方法，由于都还属于项目边界内，建议直接throw异常，而非返回Result模型，避免层层解析处理；

对于Controller层/全局异常处理成，由于是项目与外部的交互边界，建议返回统一规范的Result模型

错误码
业务规则错误码
1.是否抛给调用方（如前端）？是，并且建议调用方在客户端上呈现（比如商户官网、saas后台等）

2.是否有必要全局（整个速保项目体系）统一定义？否，根据自身业务需要自行定义，即使以后要做统一API输出体系，相同的错误码也可通过 所属业务标识 进行区分

系统异常错误码
1.是否抛给调用方（如前端页面）？否，两个考虑点：

a.从客户体验的角度看，系统异常抛到前端页面，客户看不懂，只会额外增加困扰。PS：快速定位问题，不应该把成本转嫁给用户，不应该寄期望于用户提供包含系统错误码的错误截图去反馈问题
b.从系统建设的角度看，系统异常属于技术细节，应该封装到系统内部，对调用方屏蔽
2.是否有必要全局（整个速保项目体系）统一定义？否

建议各个project内部定义自身需要关注的系统错误码，并且在对调用方返回时，返回速保项目约定一致的系统错误码 ("-1", "系统繁忙，请稍后再试！", "服务器暂不可用，建议稍候重试。")
调用方project拿到系统错误码返回后，根据自身需要做进一步处理（比如直接抛出，或者转换成内部错误，或者直接进入到特定的逻辑处理分支等等）