springboot 上传异常捕获_SpringBoot中如何实现接口的统一返回和异常的统一捕获

接口的统一返回

在开发公司接口时,发现Controller层的接口返回都需要用一个Result包裹,如下图所示:

ab4340782e724eeb8461fc5a449bd0a1.png

图示代码中无论是创建接口或者查询接口,这里都需要用一个Result去接收,我们来看看Result的结构:

a3d60b26b6a17b0916a4ace5c1dc5814.png

这个Result中有几个字段:

code:状态码

message:状态信息

data:装载正真返回的数据

exception:异常数据

然后我们测试下接口,看看返回样式:

50f3eb62b21f2e6830a9632ce596e838.png
95443df6d824ff68b3b495407e4fbe1c.png

调用接口,返回格式为:

{  "code": 200,  "message": "SUCCESS",  "data": {      ...  }  "exception": xxx}

写完后我就在思考,每个接口都需要包一层Result,感觉影响了接口的可读性。作为开发来说这样包裹一层也很麻烦。

那么有没有一种方法,可以通过框架自动包裹一层Result,开发只要在Controller层直接返回实体就行了呢?

还真有这样的方法,能实现Controller层接口的统一返回:

36d0268736bbdcc396c1a27604e2b8f2.png

如上代码,我们使用ResponseBodyAdvice来拦截Controller层方法默认返回参数。说白了就是个拦截器。主要是看beforeBodyWrite()方法,在这个方法中,如果Controller中的返回已经是Result,那就直接返回Result。如果不是,那就使用Result去包装。

我们来看看效果:

2a08413b5cbb4e516678bba52b8f1695.png

如上代码,我们直接返回实体,我们看看Swagger的返回:

1b45c82592ecc18f34ae4dfc0bb002cf.png

swagger的返回的格式是我们拦截器的格式。

这里我又有一个疑问,接口正常返回已经被Result包裹了,如果接口抛异常该怎么返回一样的格式呢?

全局的异常捕获

这里就需要全局的异常捕捉了。关于全局异常捕捉,相信很多童鞋都知道了:

0fb34286b9bbe8496b62987e60c62210.png

我们需要写一个捕捉类,在上面添加@ControllerAdvice注解,然后编写处理异常的方法:

e93d83a9d088676351ab1b9f734ec4f1.png

我们添加@ResponseBody注解和@ExceptionHandler注解,这里的value = Exception.class,表示我们捕捉Exception类型的异常。我们就可以直接抛异常了:

01e550a5bd2a7610b6f14a19914beb41.png

也可以这么抛:

7cc8a9c7e92a901d43ad38718ad58204.png

我们测试,如果代码抛异常,接口就会返回:

e70a0f2a728e010a9c30fed2b5c74f68.png

格式符合预期。

但是这里还是有一个问题,每次我都需要写if语句:

if(条件) {   throw new RuntimeException("...");}

这样写还是太麻烦,而且啥异常都抛RuntimeException。这样还是太粗糙了。

于是我决定自定义一个业务异常,并且封装一些异常抛出方法,说干就干。

自定义业务异常

f3d41d43ac9794022dc5c795790d0ea7.png

我们定义一个业务异常,这里面封装了异常状态码,和异常信息数据。

优雅抛异常

然后我们编写一个业务异常判断类:

058e8d6b54a3e53a9a6b3738ef80dc75.png

这里只截取了部分代码,里面其实只有两个方法checkArgument()和checkNotNull()。他们有什么用呢?如果要做非空校验,一般是这么做的:

if (updateEntity == null) {    throw new RuntimeException("传入参数为null");}

但是现在可以这么做了:

BusinessExceptionAssert.checkNotNull(updateEntity, "参数不能为null");

抛出的是我自定义的业务异常。

如果是一般的逻辑校验呢?以前的代码是这么写的:

if(!"1".equals(id)) {   throw new RuntimeException(String.format("参数id【%s】只能为1",id));}

现在可以有更优雅的实现方式:

BusinessExceptionAssert.checkArgument("1".equals(id), 500, "参数id【%s】只能为1",id);

因为抛的是业务异常,我们还可以自定义异常码。

完整测试代码:

 @ApiOperation(value = "test-测试异常", httpMethod = "POST", notes = "测试代码,勿动") @PostMapping(value = "testBusinessException") public int testBusinessException(@RequestParam String id) {     BusinessExceptionAssert.checkArgument("1".equals(id), 500, "参数id【%s】只能为1",id);     return 1; }

我们测试结果:

61cf94bd75159c4cccbf534f8afc1c64.png

符合预期。

这篇文章写到这里就结束了,本文主要讲解了:

如何实现接口统一返回

如何自定义业务异常,并被统一捕获

如何优雅的抛异常

如果还有改进的,欢迎大家积极交流。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值