项目踩坑之面试遇到的问题及解决

第一点：

问题

遇到的问题之：在实现后台管理端-账户操作的时候，添加员工的时候如果重复添加同一个员工，会触发一个数据库唯一约束异常，但客户端无法清晰的理解这个错误，所以我们就对新增员工的代码进行try catch，但同时带来一个问题，代码量一旦上来就不可行。

解决：

这里我们使用SpringAop思想实现全局异常拦截处理，从而对异常的统一处理。

当报错信息出现Duplicate entry时，就意味着新增员工异常了 所以，我们对异常类的方法进行一些小改动，让这个异常反馈变得更人性化 这个时候再来客户端试试，就会提供人性化的报错，非常的快乐~，更加人性化，体验更好。

实现代码：

//@RestControllerAdvice包括了下面两行
@ControllerAdvice(annotations = {RestController.class, Controller.class})
@ResponseBody
@Slf4j
public class GlobalExceptionHandler {
 
    /**
     * 异常处理方法
     * @return
     */
    //捕获完整性约束违反异常（其实就是数据库唯一约束异常）SQLIntegrityConstraintViolationException
    @ExceptionHandler(SQLIntegrityConstraintViolationException.class)
    public R exceptionHandler(SQLIntegrityConstraintViolationException ex){
        log.error(ex.getMessage());
 
        if(ex.getMessage().contains("Duplicate entry")){
            return R.error("唯一约束异常:"+exception.getMessage().split(" ")[2]+"已存在");
        }
 
        return R.error("未知唯一约束错误");
    }
}

这回再回到Controller，这时就不需要再来try catch这种形式了，不用管他，因为一旦出现错误就会被我们的AOP捕获。所以，不需要再用try catch来抓了

第二点

问题：

启用禁用员工账号，js主键丢失精度问题

只有管理员账号有禁用启用按钮：

前端如何判断当前用户是admin？缓存：local Storage里面

点击禁用后发送请求：

js丢失long精度问题

Long类型id是19位，而js只能处理17位数字，Long类型主键从前端传回后端丢失精度，导致传到后端的id和数据库id不一致：

解决方案：

实体类注解@JsonFormat

实现代码：

在员工的主键上面加上@JsonFormat

  @JsonFormat(shape = JsonFormat.Shape.STRING)
    private Long id;