前言
在业务逻辑中,通常使用两种方式处理异常:
- 返回错误码:优点是性能更好,但是不宜维护。
- 抛出异常:可以使得代码更清晰,可读性更好,更符合面向对象。
选择哪种需要根据场景而定,不管如何选择,只要团队达成共识,统一规范就可以。
下面介绍一下我使用的处理异常的方式。
自定义异常
创建一个业务异常基类 BaseException extends RuntimeException ,为其添加两个属性:code 和 message ,并添加一些常用的构造方法。
其中, **code **的作用是储存错误码,在返回前台时将错误码返回给用户。

抛出异常:

错误码管理
上面的自定义异常看起来很简单,但是不够优雅和简单。怎么将错误码和错误信息管理起来,是我们接下来要解决的问题。
我使用了 Enum ,先创建一个接口,其中包含两个方法:
- toCode():将枚举值转为 int 错误码,默认已实现;
- getMsg():获取枚举中的异常信息。

下面创建一个枚举类,实现上面的接口:

观察上面的错误码枚举类,我们发现,枚举值为 字母+错误码 ,属性 msg 为错误信息。
这样将错误码和异常信息统一管理起来之后,抛出异常的代码就可优化为:

然而这样依然不够优雅,代码量比之前还要长。要是能够只传枚举值一个参数就好了,那么我们继续优化。
创建一个异常类 BusinessException extends BaseException (创建一个子类,用来接收枚举值),如下:

这样我们就可以优雅的抛出 BusinessException 了:

如果想要保留原异常信息,还可以使用:

以上就是对异常处理的封装,使用时,只需要在每个业务模块中新建一个异常枚举类,用来统一管理异常;需要时,在代码中抛出 BusinessException 即可。
统一异常处理
最后,我们再使用 @ControllerAdvice 和 @ExceptionHandler 注解做一下统一异常处理,它的作用是:
- 将业务异常打印到日志中
- 将系统异常封装为 BaseException 进行返回,同样打印日志;
- 这里也可以做其他操作,比如短信提醒等。
代码如下:


-
接口
+关注
关注
33文章
9449浏览量
156160 -
代码
+关注
关注
30文章
4942浏览量
73159 -
异常处理
+关注
关注
0文章
15浏览量
7448 -
储存
+关注
关注
3文章
203浏览量
22959
发布评论请先 登录
嵌入式C编程常用的异常错误处理
挂载sramfs文件系统到外挂sdram ,挂载时返回错误码为-1,怎么解决?
LabVIEW找不到错误码,USRP
Linux如何查看系统提供的错误码
为什么ucosiii发送消息会显示错误码OS_ERR_INT_Q_FULL?
Oracle错误码大全
微辰金服新中付POS商户警惕这五个错误码
Bada系统学习-错误码(Error Codes)
C++异常机制解析

异常处理和错误码管理
评论