1. 为什么需要规范的异常处理?
首先,规范异常处理也是为了后期能更好的维护,减少程序出错,别再哪里都try{}catch(){},对于有强迫症的我,规范处理异常是必不可少的;规范异常处理能让你代码变得更加整洁、干净。
2. 异常处理分类
异常处理方式:
service抛出异常,controller统一try{}catch(){}
对于一些io、http请求异常能直接处理的就直接try{}catch(){}处理
controller不处理异常,通过@ControllerAdvice 定义部分类型的异常进行处理
@ControllerAdvice
public class WebExceptionHandler {
@ExceptionHandler({ BizException.class })
@ResponseStatus(HttpStatus.OK)
public String processBizException(HttpServletRequest request, BizException e) {
LOG.error("BizException", e);
request.setAttribute("msg", e.getMsg());
return "common/error";
}
}
异常分类:
请求方式异常
参数异常,如:使用@RequestParam但请求时参数未传框架会抛出异常可以全局捕获处理@ControllerAdvice
业务异常,如:用户不存在、验证码失效,业务异常又可以根据不同的业务进行跟细化的分类,用户异常、账户异常..
系统异常,如:参数不对导致查询到的结果集多个
给请求方异常编码分类:
public enum ReturnCodeEnum {
SUCCESS("0000","请求成功"),
MERCHANT_ERROR("0001","商户异常"),
ORDER_IS_NULL("0002","原始订单不存在"),
WAITING_PAYER_CONFIRM("9995","等待客户确认"),
WAITING("9996","请求处理中"),
FAIL("9997","请求失败"),
BIZ_ERROR("9998","业务异常"),
SYSTEM_EXCEPTION("9999","系统异常");
}
内部异常编码分类:
/**
* 银行设置异常类
*/
public class BankBizException extends BizException {
private static final long serialVersionUID = 3536909333010163563L;
/** 不存在通道分流设置 **/
public static final int CHANNEL_FLOW_IS_NULL = 101;
/** 请求参数异常 **/
public static final int REQUEST_PARAM_ERRO = 102;
/** 银行渠道配置错误 **/
public static final int BANK_CHANNEL_ERRO = 103;
/** 银行渠道错误 **/
public static final int BANK_WAY_ERROR = 104;
/** 子商户的银行渠道附属信息为空 **/
public static final int BANK_SUBMERCHANT_INFO_IS_NULL = 105;
/** 子商户的银行渠道附属信息配置错误 **/
public static final int BANK_SUBMERCHANT_INFO_IS_ERROR = 106;
/** 验证银行渠道传的参数不符合要求 **/
public static final int BANK_CHANNEL_RULE_VALIDA_PARAM_ERROR = 107;
/** agui 银行渠道开放时间错误 **/
public static final int BANK_CHANNEL_DATE_ERRO = 108;
}
这里为什么使用区分请求方和内部方式统一管理异常编码?
首先我们需要给到请求方统一的请求和响应编码表,能让请求方根据不同的异常编码进行分类处理,而对内的异常编码是为了平台内部统计或记录异常信息,更有利于排查问题。业务异常的message要明确,可以直接返回给请求方定位错误,但系统异常message不能直接返回给请求方,可以提示为:系统异常,请稍后再试,因为的异常message可能是框架抛出来的,需要我们手动处理,我们只能定时记录这些异常LOG日志,后期分类优化。
3. 总结
值得注意的一些事
异常信息需要通过LOG收集并分析
合理异常分类
异常编码统一管理