Spring Boot开发（四）统一异常、JSR303数据校验处理

实际项目开发中，程序往往会发生各式各样的异常情况，特别是身为服务端开发人员的我们，总是不停的编写接口提供给前端调用，分工协作的情况下，避免不了异常的发生，如果直接将错误的信息直接暴露给用户，这样的体验可想而知，且对黑客而言，详细异常信息往往会提供非常大的帮助…

Spring Boot 提供了一套默认的异常处理机制，一旦程序中出现了异常，Spring Boot 会自动识别客户端的类型（浏览器客户端或机器客户端），并根据客户端的不同，以不同的形式展示异常信息。

1. 对于浏览器客户端而言，Spring Boot 会响应一个“ whitelabel”错误视图，以 HTML 格式呈现错误信息，如图

springboot中，默认在发送异常时，会跳转值/error请求进行错误的展现，根据不同的Content-Type展现不同的错误结果，如json请求时，直接返回json格式参数。

2. 对于机器客户端而言，Spring Boot 将生成 JSON 响应，来展示异常消息。
   
   Spring Boot 提供的默认异常处理机制却并不一定适合我们实际的业务场景，因此，我们通常会根据自身的需要对 Spring Boot 全局异常进行统一定制，例如定制错误页面，定制错误数据等。

在web应用中，请求处理时，出现异常是非常常见的。所以当应用出现各类异常时，进行异常的捕获或者二次处理(比如sql异常正常是不能外抛)是非常必要的，比如在开发对外api服务时，约定了响应的参数格式，如respCode、respMsg，调用方根据错误码进行自己的业务逻辑。

显然，默认的异常页是对用户或者调用者而言都是不友好的，所以一般上我们都会进行实现自己业务的异常提示信息。

利用@ControllerAdvice和@ExceptionHandler定义一个统一异常处理类

• @ControllerAdvice：控制器增强，使@ExceptionHandler、@InitBinder、@ModelAttribute注解的方法应用到所有的
  @RequestMapping注解的方法。
• @ExceptionHandler：异常处理器，此注解的作用是当出现其定义的异常时进行处理的方法

@ControllerAdvice
public class CommonExceptionHandler {

    
    @ExceptionHandler(Exception.class)
    @ResponseBody
    public Map exceptionHandler(Exception e){
        Map result = new HashMap();
        result.put("respCode", "9999");
        result.put("respMsg", e.getMessage());
        //正常开发中，可创建一个统一响应实体，如CommonResp
        return result; 
    }
}

多余不同异常(如自定义异常)，需要进行不同的异常处理时，可编写多个exceptionHandler方法，注解ExceptionHandler指定处理的异常类，如

@ExceptionHandler(CommonException.class)
@ResponseBody
public Map exceptionHandler(CommonException ex){
    log.info("CommonException：{}({})",ex.getMsg(), ex.getCode());
    Map result = new HashMap();
    result.put("respCode", ex.getCode());
    result.put("respMsg", ex.getMsg());
    return result; 
}

由于加入了@ResponseBody，所以返回的是json格式，

可拦截不同的异常，进行不同的异常提示，比如NoHandlerFoundException、HttpMediaTypeNotSupportedException、AsyncRequestTimeoutException等等

对于返回页面时，返回ModelAndView即可，如

@ExceptionHandler(value = Exception.class)
    public ModelAndView defaultErrorHandler(HttpServletRequest req, Exception e) throws Exception {
        ModelAndView mav = new ModelAndView();
        mav.addObject("exception", e);
        mav.addObject("url", req.getRequestURL());
        mav.setViewName(DEFAULT_ERROR_VIEW);
        return mav;
    }

由于工作中都是才有前后端分离开发模式，所以一般上都没有直接返回资源页的需求了，一般上都是返回固定的响应格式，如respCode、respMsg、data，前端通过判断respCode的值进行业务判断，是弹窗还是跳转页面。

对于任何一个应用而言，客户端做的数据有效性验证都不是安全有效的，而数据验证又是一个企业级项目架构上最为基础的功能模块，这时候就要求我们在服务端接收到数据的时候也对数据的有效性进行验证。为什么这么说呢？往往我们在编写程序的时候都会感觉后台的验证无关紧要，毕竟客户端已经做过验证了，后端没必要在浪费资源对数据进行验证了，但恰恰是这种思维最为容易被别人钻空子。毕竟只要有点开发经验的都知道，我们完全可以模拟 HTTP 请求到后台地址，模拟请求过程中发送一些涉及系统安全的数据到后台，后果可想而知….

在web开发时，对于请求参数，一般上都需要进行参数合法性校验的，原先的写法时一个个字段一个个去判断，这种方式太不通用了，所以java的JSR 303: Bean Validation规范就是解决这个问题的。

Springboot中可以用@validated来校验数据，如果数据异常则会统一抛出异常，方便异常中心统一处理。我们这里来写个注解让我们的name只能支持Email格式；

@Component //注册bean
@ConfigurationProperties(prefix = "person")
@Validated  //数据校验
public class Person {

    @Email(message="邮箱格式错误") //name必须是邮箱格式
    private String name;
}

运行结果 ：default message [不是一个合法的电子邮件地址];

使用数据校验，可以保证数据的正确性；

@NotNull(message="名字不能为空")
private String userName;
@Max(value=120,message="年龄最大不能查过120")
private int age;
@Email(message="邮箱格式错误")
private String email;

空检查
@Null       验证对象是否为null
@NotNull    验证对象是否不为null, 无法查检长度为0的字符串
@NotBlank   检查约束字符串是不是Null还有被Trim的长度是否大于0,只对字符串,且会去掉前后空格.
@NotEmpty   检查约束元素是否为NULL或者是EMPTY.
    
Booelan检查
@AssertTrue     验证 Boolean 对象是否为 true  
@AssertFalse    验证 Boolean 对象是否为 false  
    
长度检查
@Size(min=, max=) 验证对象（Array,Collection,Map,String）长度是否在给定的范围之内  
@Length(min=, max=) string is between min and max included.

日期检查
@Past       验证 Date 和 Calendar 对象是否在当前时间之前  
@Future     验证 Date 和 Calendar 对象是否在当前时间之后  
@Pattern    验证 String 对象是否符合正则表达式的规则

.......等等
除此以外，我们还可以自定义一些数据校验规则