十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
前言
“只有客户发展了,才有我们的生存与发展!”这是成都创新互联公司的服务宗旨!把网站当作互联网产品,产品思维更注重全局思维、需求分析和迭代思维,在网站建设中就是为了建设一个不仅审美在线,而且实用性极高的网站。创新互联对成都网站设计、成都网站制作、网站制作、网站开发、网页设计、网站优化、网络推广、探索永无止境。
系统很多地方都会抛出异常, 而Java的异常体系目标就是与逻辑解耦,Spring提供了统一的异常处理注解,用户只需要在错误的时候提示信息即可
在具体的SSM项目开发中,由于Controller层为处于请求处理的最顶层,再往上就是框架代码的。
因此,肯定需要在Controller捕获所有异常,并且做适当处理,返回给前端一个友好的错误码。
不过,Controller一多,我们发现每个Controller里都有大量重复的、冗余的异常处理代码,很是啰嗦。
能否将这些重复的部分抽取出来,这样保证Controller层更专注于业务逻辑的处理,
同时能够使得异常的处理有一个统一的控制中心点。
下面话不多说了,来一起看看详细的介绍吧
1. 全局异常处理
1.1. HandlerExceptionResolver接口
public interface HandlerExceptionResolver { /** * Try to resolve the given exception that got thrown during on handler execution, * returning a ModelAndView that represents a specific error page if appropriate. *The returned ModelAndView may be {@linkplain ModelAndView#isEmpty() empty} * to indicate that the exception has been resolved successfully but that no view * should be rendered, for instance by setting a status code. * @param request current HTTP request * @param response current HTTP response * @param handler the executed handler, or {@code null} if none chosen at the * time of the exception (for example, if multipart resolution failed) * @param ex the exception that got thrown during handler execution * @return a corresponding ModelAndView to forward to, * or {@code null} for default processing */ ModelAndView resolveException( HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex); }
使用全局异常处理器只需要两步:
在resolveException中实现异常处理逻辑。
从参数上,可以看到,不仅能够拿到发生异常的函数和异常对象,还能够拿到HttpServletResponse对象,从而控制本次请求返回给前端的行为。
此外,函数还可以返回一个ModelAndView对象,表示渲染一个视图,比方说错误页面。
不过,在前后端分离为主流架构的今天,这个很少用了。如果函数返回的视图为空,则表示不需要视图。
1.2. 使用示例
来看一个例子:
@Component @Slf4j public class CustomHandlerExceptionResolver implements HandlerExceptionResolver { @Override public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { Method method = null; if (handler != null && handler instanceof HandlerMethod) { method = ((HandlerMethod) handler).getMethod(); } log.error("[{}] system error", method, ex); ResponseDTO response = ResponseDTO.builder() .errorCode(ErrorCode.SYSTEM_ERROR) .build(); byte[] bytes = JSON.toJSONString(response).getBytes(StandardCharsets.UTF_8)); try { FileCopyUtils.copy(bytes, response.getOutputStream()); } catch (IOException e) { log.error("error", e); throw new RuntimeException(e); } return new ModelAndView(); } }
逻辑很显然,在发生异常时,将ResponseDTO序列化为json给前端。
1.3. Controller局部异常处理
1.3.1. 使用示例
这种异常处理只局部于某个Controller内,如:
@Controller @Slf4j @RequestMapping("/api/demo") public class DemoController { @ExceptionHandler(Exception.class) @ResponseBody public ResponseDTO<?> exceptionHandler(Exception e) { log.error("[{}] system error", e); return ResponseDTO.builder() .errorCode(ErrorCode.SYSTEM_ERROR) .build(); } }
此外,它还能够对异常类型进行细粒度的控制,通过注解可以有选择的指定异常处理方法应用的异常类型:
@ExceptionHandler({BusinessException.class, DataBaseError.class })
虽然说全局异常处理HandlerExceptionResolver通过条件判断也能做到,
但是使用这种注解方式明显更具有可读性。
1.3.2. 一个问题
刚才说到异常处理函数可以用@ResponseBody修饰,就像一般的Controller方法一样。
然而,非常遗憾的是,如果使用自定义的HandlerMethodReturnValueHandler,却不生效。
比如:
@ExceptionHandler(Exception.class) @JsonResponse public ResponseDTO<?> exceptionHandler(Exception e) { log.error("[{}] system error", e); return ResponseDTO.builder() .errorCode(ErrorCode.SYSTEM_ERROR) .build(); }
不知道是我的使用姿势不对,还是什么情况?各种google后无果。
所以,目前的解决方案是,如果能够控制@JsonResponse注解相关的定义代码,将处理返回值这部分逻辑抽取出来,然后在异常处理函数中手动调用。
1.4. ControllerAdvice
1.4.1. 使用示例
刚才介绍的是Controller局部的异常处理,用于处理该Controller内部的特有的异常处理十分有用。
首先,定义一个存放异常处理函数的类,并使用@ControllerAdvice修饰。
@ControllerAdvice(assignableTypes = {GlobalExceptionHandlerMixin.class}) public class ExceptionAdvice { @ExceptionHandler(ErrorCodeWrapperException.class) @ResponseBody public ResponseDTO<?> exceptionHandler(ErrorCodeWrapperException e) { if ((errCodeException.getErrorCode().equals(ErrorCode.SYSTEM_ERROR))) { log.error(e); } return ResponseDTO.ofErroCodeWrapperException(errCodeException); } }
@ExceptionHanlder修饰的方法的写法和Controller内的异常处理函数写法是一样的。
1.4.2. 控制生效的Controller范围
注意到,我是这样编写注解的:
@ControllerAdvice(assignableTypes = {GlobalExceptionHandlerMixin.class})
它用来限定这些异常处理函数起作用的Controller的范围。如果不写,则默认对所有Controller有效。
这也是ControllerAdvice进行统一异常处理的优点,它能够细粒度的控制该异常处理器针对哪些Controller有效,这样的好处是:
也就是说,如果不控制生效范围,即默认对所有Controller生效。如果控制生效范围,则默认对所有Controller不生效,降低侵入性。
如刚才示例中的例子,只针对实现了GlobalExceptionHandlerMixin接口的类有效:
@Controller @Slf4j @RequestMapping("/api/demo") public class DemoController implements GlobalExceptionHandlerMixin { }
ControllerAdvice支持的限定范围:
@ControllerAdvice(annotations = RestController.class)
@ControllerAdvice("org.example.controllers")
@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})
2. 总结
以上几种方式是Spring专门为异常处理设计的机制。
就我个人而言,由于ControllerAdvice具有更细粒度的控制能力,所以我更偏爱于在系统中使用ControllerAdvice进行统一异常处理。
除了用异常来传递系统中的意外错误,也会用它来传递处于接口行为一部分的业务错误。
这也是异常的优点之一,如果接口的实现比较复杂,分多层函数实现,如果直接传递错误码,那么到Controller的路径上的每一层函数都需要检查错误码,退回到了C语言那种可怕的“写一行语句检查一下错误码”的模式。
当然,理论上,任何能够给Controller加切面的机制都能变相的进行统一异常处理。比如:
好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对创新互联的支持。