最近在用spring boot 做微服务,所以对于异常信息的 【友好展示】有要求,我设计了两点:
一、 在业务逻辑代码中,异常的抛出 我做了限定,一般只会是三种:
1. OmcException //自己写的异常包装类 ,主要用来处理业务异常 2. IllegalArgumentException //参数异常类,其实这个可以不要,只是在我的系统中,我想把参数异常和业务异常做区分 3. 其他的异常,都按Exception抛 //因为它的抽象层次最高,所以在系统中按优先级最低进行处理,除非必要(如容器级错误)否则尽量避免
OmcException的构造是这样的:
这里留个钩子:
为什么要在抛异常时,带上 日志的信息 + 输入参数的信息?
—— 因为,我希望在业务逻辑代码中,对于这些异常的处理,最好就是一行代码,类似于:打印error日志 + 向用户返回友好的错误信息。我想做一个公共的处理模块。让业务逻辑代码尽可能的清爽一些。
对异常的进行try-catch包装的过程是:
对异常的抛出做限定,给个总结就是:尽量包装成我们自己封装的异常包装类。
为什么呢? 这是在设计上做限定,那么后进的程序员,如果不按照这个规范走,功能是做不出来的。这个也是架构设计的意义,不要随便动个嘴就好,还要把栅栏建好。
二、 在公共的业务逻辑处理代码中,异常的接收(或者说异常的路由) 我做了限定,一般是:
1. 先匹配业务异常。业务异常一般向用户提示什么呢? 错误编码 + 错误提示信息。
2. 其次,匹配参数异常,这些参数异常可能是我们自己做参数校验抛出来的,也有可能是spring mvc 抛出来的,所以还没有到我们的业务逻辑代码中。
参数异常一般提示什么呢? 错误提示信息(包含哪个字段出现了错误)
3. 根异常Exception,这里捕获的异常,可能是我们不愿意处理的 数据库异常,也有可能是容器报的异常(当然,这些异常我们并不能捕获所有的。)这里要做打error日志的处理。
一个设计良好的系统,最好是不要走进这个分支,毕竟分析error日志不是一件多么光荣的事儿。
spring boot中,公共异常处理模块代码结构是:
然后是,打印error日志 + 向用户返回友好的错误信息