系统异常设计规范与原则

1.内部异常
a.资源环境导致(系统环境异常,数据库连接超时,第三方服务响应超时)
b.第三方服务错误响应
c.第三方响应结果错误
d.外部传入参数非法
e.错误的编码逻辑
f.错误的配置
g.异常的业务数据(业务数据缺失)
2.业务异常
a.用户操作错误
b.业务条件不满足

其次需要在系统中正确的捕获这类异常,并抛出
1.方法入参进行合法性验证

  • a.对系统外部提供的接口,是必须要进行参数验证(必须)
  • b.系统内部对外层提供接口,进行验证
  • c.工具类进行参数验证
  • d.public方法要进行验证
  • e.private 方法(不建议参数验证)

2.第三方响应结果合法性验证

  • a. 获取第三方结果,根据约定进行验证

3.业务处理前,对业务前置条件进行验证

  • a. 业务处理前,验证业务条件(验证余额,验证这个账户有没有被公安部门锁定)
  • b.要考虑性能成本(验证身份证号码是不是存在的)

4.业务处理后,对处理结果进行验证

  • a.验证对方账户是否到账,转出账户是否成功扣款

5.对于可能会出现异常的代码进行try catch捕获

  • a.尝试恢复处理
  • b.直接抛出
  • c.转换后抛出

最后在系统的出口统一拦截处理。
统一拦截的目的是确保出去的异常是可控的,调用方能够明白异常信息。
这里出口是指系统对外统一响应逻辑,一般我们可分三类场景

1.WEB Response

  • a.内部异常:导致异常提示页。
  • b.业务异常:返回对应提示消息至前端。

2.Http API 接口响应

  • a.内部异常:返回接口不可用消息。
  • b.参数错误:基于API文档中的异常列表进行响应返回。表明参数非法,需要调用方加强参数合法性验证
  • c.业务错误:基于接口约定返回对应code与消息

3.RPC Service 响应

  • a.内部异常:返回服务不可用消息
  • b.参数错误:基于接口文档进行响应,直接返回异常堆栈
  • c.业务错误:直接返回异常堆栈

总结:定义归类异常 捕获异常 拦截处理异常

checkedException 与 uncheckedException声明原则
1.如果参数非法抛出,返回结果非法(即软件BUG)uncheckedException
2.如果你认为调用方程序员需要有意识地采取措施,那么抛出检查型异常
3.程序产品有明确的条件约束,可声明检测型业务异常

Java 业务异常实战
异常的定义技巧
基于分包表示异常的分类,不建议使用继承
创建异常来类定义业务异常,不建议使用Code来定义
使用枚举来表示业务异常的几种结果,不建议使用code
统一对异常进行分类处理
异常转换
异常信息处理
逻辑断言
参数合法性验证
返回结果合法性验证

异常捕获
统一对异常进行拦截处理
目的:防止不明确的异常流出系统
RPC Service 响应拦截
Web Control 响应拦截
Http API 响应拦截
常见的错误的异常处理方式

直接勿略异常:
try {
new String(source.getBytes(“UTF-8”), “GBK”);
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
正确的处理
try {
new String(source.getBytes(“UTF-8”), “GBK”);
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(“环境不支持UTF-8”,e)
}

业务异不提供任何信息
public class DuplicateUsernameException extends Exception {
}
给每个异常处理都定义一个Code

用一个统一异常替代所有业务异常
public class ServiceException extends RuntimeException {

public ServiceException(Exception e) {
super(e);
}

public ServiceException(String message) {
super(message);
}
}
错误:1 、必须明确定义业务异常 2、 尽可能申明成checkedException 3要带上具体的业务数
正确方式:定义明确的业务异常

你可能感兴趣的:(java)