type
status
date
slug
summary
tags
category
icon
password
URL
为啥需要统一异常
日常开发，程序难免会因为某些原因抛出异常，一般都是try或者throw.这种方式对于程序猿来说处理起来很麻烦，并且过多的关注了非业务逻辑，对客户端也不友好。这时候全局异常处理就显得特别重要了
统一结果和统一异常
统一返回结构后，在 Controller 中就可以使用了，但是每一个 Controller 都写这么一段最终封装的逻辑，这些都是很重复的工作，所以还要继续想办法进一步处理统一返回结构。
统一包装处理
Spring 中提供了一个类 ResponseBodyAdvice ，能帮助我们实现上述需求：
ResponseBodyAdvice 是对 Controller 返回的内容在 HttpMessageConverter 进行类型转换之前拦截，进行相应的处理操作后，再将结果返回给客户端。
那这样就可以把统一包装的工作放到这个类里面：
- supports： 判断是否要交给 beforeBodyWrite 方法执行，ture：需要；false：不需要
- beforeBodyWrite： 对 response 进行具体的处理
经过这样改造，既能实现对 Controller 返回的数据进行统一包装，又不需要对原有代码进行大量的改动。
参数校验
Java API 的规范 JSR303 定义了校验的标准 validation-api ，其中一个比较出名的实现是 hibernate validation。
spring validation 是对其的二次封装，常用于 SpringMVC 的参数自动校验，参数校验的代码就不需要再与业务逻辑代码进行耦合了。
@PathVariable 和 @RequestParam 参数校验
Get 请求的参数接收一般依赖这两个注解，但是处于 url 有长度限制和代码的可维护性，超过 5 个参数尽量用实体来传参。
对 @PathVariable 和 @RequestParam 参数进行校验需要在入参声明约束的注解。
如果校验失败，会抛出 MethodArgumentNotValidException 异常。
校验原理
声明约束的方式，注解加到了参数上面，可以比较容易猜测到是使用了 AOP 对方法进行增强。
而实际上 Spring 也是通过 MethodValidationPostProcessor 动态注册 AOP 切面，然后使用 MethodValidationInterceptor 对切点方法进行织入增强。
自定义校验规则
有些时候 JSR303 标准中提供的校验规则不满足复杂的业务需求，也可以自定义校验规则。
自定义校验规则需要做两件事情：
- 自定义注解类，定义错误信息和一些其他需要的内容
- 注解校验器，定义判定规则
自动校验参数真的是一项非常必要、非常有意义的工作。JSR303 提供了丰富的参数校验规则，再加上复杂业务的自定义校验规则，完全把参数校验和业务逻辑解耦开，代码更加简洁，符合单一职责原则。
自定义异常和统一拦截异常
原来代码中的问题
- 抛出的异常不够具体，只是简单地把错误信息放到了 Exception 中
- 抛出异常后，Controller 不能具体地根据异常做出反馈
- 虽然做了参数自动校验，但是异常返回结构和正常返回结构不一致
自定义异常是为了后面统一拦截异常时，对业务中的异常有更加细颗粒度的区分，拦截时针对不同的异常作出不同的响应。
而统一拦截异常的目的一个是为了可以与前面定义下来的统一包装返回结构能对应上，另一个是我们希望无论系统发生什么异常，Http 的状态码都要是 200 ，尽可能由业务来区分系统的异常。
致谢：
有关Notion安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~
- 作者:卷神
- 链接:https://blog.952712.xyz/article/30961def-6cad-46e0-8946-4e67eea4fc9c
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
