我的编程空间,编程开发者的网络收藏夹
学习永远不晚

SpringMVC 异常处理体系深入分析

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

SpringMVC 异常处理体系深入分析

SpringMVC 中针对异常问题有一套完整的处理体系,这套体系非常好用,今天松哥就花点时间来和大家聊一聊 SpringMVC 中的异常处理体系,我们把 SpringMVC 中的异常体系从头到尾梳理一下。

1.异常解析器概览

在 SpringMVC 的异常体系中,处于最顶层的大 Boss 是 HandlerExceptionResolver,这是一个接口,里边只有一个方法:

  1. public interface HandlerExceptionResolver { 
  2.  @Nullable 
  3.  ModelAndView resolveException( 
  4.    HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex); 

resolveException 方法就用来解析请求处理过程中所产生的异常,并最终返回一个 ModelAndView。

我们来看下 HandlerExceptionResolver 的实现类:

直接实现 HandlerExceptionResolver 接口的类有三个:

  • HandlerExceptionResolverComposite:这个一看又是一个组合,在最近的源码分析中我们已经多次见到 xxxComposite 了,这里就不再赘述。
  • DefaultErrorAttributes:这个用来保存异常属性。
  • AbstractHandlerExceptionResolver:这个的子类比较多:
    • SimpleMappingExceptionResolver:通过提前配置好的异常类和 View 之间的对应关系来解析异常。
    • AbstractHandlerMethodExceptionResolver:处理使用 @ExceptionHandler 注解自定义的异常类型。
    • DefaultHandlerExceptionResolver:按照不同类型来处理异常。
    • ResponseStatusExceptionResolver:处理含有 @ResponseStatus 注解的异常。

在 SpringMVC 中,大致的异常解析器就是这些,接下来我们来逐个学习这些异常解析器。

2.AbstractHandlerExceptionResolver

AbstractHandlerExceptionResolver 是真正干活的异常解析器的父类,我们就先从他的 resolveException 方法开始看起。

  1. @Override 
  2. @Nullable 
  3. public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) { 
  4.  if (shouldApplyTo(request, handler)) { 
  5.   prepareResponse(ex, response); 
  6.   ModelAndView result = doResolveException(request, response, handler, ex); 
  7.   if (result != null) { 
  8.    logException(ex, request); 
  9.   } 
  10.   return result; 
  11.  } 
  12.  else { 
  13.   return null
  14.  } 
  1. 首先调用 shouldApplyTo 方法判断当前解析器是否可以处理传入的处理器所抛出的异常,如果不支持,则直接返回 null,这个异常将交给下一个 HandlerExceptionResolver 去处理。
  2. 调用 prepareResponse 方法处理 response。
  3. 调用 doResolveException 方法实际处理异常,这是一个模版方法,具体的实现在子类中。
  4. 调用 logException 方法记录异常日志信息。

记录异常日志没啥好说的,doResolveException 则是一个空的模版方法,所以这里对我们来说主要就是两个方法:shouldApplyTo 和 prepareResponse,我们分别来看。

shouldApplyTo

  1. protected boolean shouldApplyTo(HttpServletRequest request, @Nullable Object handler) { 
  2.  if (handler != null) { 
  3.   if (this.mappedHandlers != null && this.mappedHandlers.contains(handler)) { 
  4.    return true
  5.   } 
  6.   if (this.mappedHandlerClasses != null) { 
  7.    for (Class handlerClass : this.mappedHandlerClasses) { 
  8.     if (handlerClass.isInstance(handler)) { 
  9.      return true
  10.     } 
  11.    } 
  12.   } 
  13.  } 
  14.  return !hasHandlerMappings(); 

这里涉及到了两个对象:mappedHandlers 和 mappedHandlerClasses:

  • mappedHandlers:存储的是处理器对象(Controller 或者 Controller 中的方法)
  • mappedHandlerClasses:存储的是处理器的 Class。

我们在配置异常解析器的时候可以配置这两个对象,进而实现该异常处理器只为某一个处理器服务,但是一般来说没这种需求,所以大家仅做了解即可。

如果开发者一开始配置了 mappedHandlers 或者 mappedHandlerClasses,则用这两个和处理器去比较,否则就直接返回 true,表示支持该异常处理。

prepareResponse

prepareResponse 方法比较简单,主要是处理一下响应头的缓存字段。

  1. protected void prepareResponse(Exception ex, HttpServletResponse response) { 
  2.  if (this.preventResponseCaching) { 
  3.   preventCaching(response); 
  4.  } 
  5. protected void preventCaching(HttpServletResponse response) { 
  6.  response.addHeader(HEADER_CACHE_CONTROL, "no-store"); 

这是 AbstractHandlerExceptionResolver 的大致内容,可以看到还是非常 easy 的,接下来我们来看它的实现类。

2.1 AbstractHandlerMethodExceptionResolver

AbstractHandlerMethodExceptionResolver 主要是重写了 shouldApplyTo 方法和 doResolveException 方法,一个一个来看。

shouldApplyTo

  1. @Override 
  2. protected boolean shouldApplyTo(HttpServletRequest request, @Nullable Object handler) { 
  3.  if (handler == null) { 
  4.   return super.shouldApplyTo(request, null); 
  5.  } 
  6.  else if (handler instanceof HandlerMethod) { 
  7.   HandlerMethod handlerMethod = (HandlerMethod) handler; 
  8.   handler = handlerMethod.getBean(); 
  9.   return super.shouldApplyTo(request, handler); 
  10.  } 
  11.  else if (hasGlobalExceptionHandlers() && hasHandlerMappings()) { 
  12.   return super.shouldApplyTo(request, handler); 
  13.  } 
  14.  else { 
  15.   return false
  16.  } 

这块感觉没啥好说的,判断逻辑基本上都还是调用父类的 shouldApplyTo 方法去处理。

doResolveException

  1. @Override 
  2. @Nullable 
  3. protected final ModelAndView doResolveException( 
  4.   HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) { 
  5.  HandlerMethod handlerMethod = (handler instanceof HandlerMethod ? (HandlerMethod) handler : null); 
  6.  return doResolveHandlerMethodException(request, response, handlerMethod, ex); 
  7. @Nullable 
  8. protected abstract ModelAndView doResolveHandlerMethodException( 
  9.   HttpServletRequest request, HttpServletResponse response, @Nullable HandlerMethod handlerMethod, Exception ex); 

doResolveException 是具体的异常处理方法,但是它里边却没有实质性操作,具体的事情交给 doResolveHandlerMethodException 方法去做了,而该方法是一个抽象方法,具体的实现在子类中。

2.1.1 ExceptionHandlerExceptionResolver

AbstractHandlerMethodExceptionResolver 只有一个子类就是 ExceptionHandlerExceptionResolver,来看下它的 doResolveHandlerMethodException 方法:

  1. @Override 
  2. @Nullable 
  3. protected ModelAndView doResolveHandlerMethodException(HttpServletRequest request, 
  4.   HttpServletResponse response, @Nullable HandlerMethod handlerMethod, Exception exception) { 
  5.  ServletInvocableHandlerMethod exceptionHandlerMethod = getExceptionHandlerMethod(handlerMethod, exception); 
  6.  if (exceptionHandlerMethod == null) { 
  7.   return null
  8.  } 
  9.  if (this.argumentResolvers != null) { 
  10.   exceptionHandlerMethod.setHandlerMethodArgumentResolvers(this.argumentResolvers); 
  11.  } 
  12.  if (this.returnValueHandlers != null) { 
  13.   exceptionHandlerMethod.setHandlerMethodReturnValueHandlers(this.returnValueHandlers); 
  14.  } 
  15.  ServletWebRequest webRequest = new ServletWebRequest(request, response); 
  16.  ModelAndViewContainer mavContainer = new ModelAndViewContainer(); 
  17.  ArrayList exceptions = new ArrayList<>(); 
  18.  try { 
  19.   if (logger.isDebugEnabled()) { 
  20.    logger.debug("Using @ExceptionHandler " + exceptionHandlerMethod); 
  21.   } 
  22.   // Expose causes as provided arguments as well 
  23.   Throwable exToExpose = exception; 
  24.   while (exToExpose != null) { 
  25.    exceptions.add(exToExpose); 
  26.    Throwable cause = exToExpose.getCause(); 
  27.    exToExpose = (cause != exToExpose ? cause : null); 
  28.   } 
  29.   Object[] arguments = new Object[exceptions.size() + 1]; 
  30.   exceptions.toArray(arguments);  // efficient arraycopy call in ArrayList 
  31.   arguments[arguments.length - 1] = handlerMethod; 
  32.   exceptionHandlerMethod.invokeAndHandle(webRequest, mavContainer, arguments); 
  33.  } 
  34.  catch (Throwable invocationEx) { 
  35.   // Any other than the original exception (or a cause) is unintended here, 
  36.   // probably an accident (e.g. failed assertion or the like). 
  37.   if (!exceptions.contains(invocationEx) && logger.isWarnEnabled()) { 
  38.    logger.warn("Failure in @ExceptionHandler " + exceptionHandlerMethod, invocationEx); 
  39.   } 
  40.   // Continue with default processing of the original exception... 
  41.   return null
  42.  } 
  43.  if (mavContainer.isRequestHandled()) { 
  44.   return new ModelAndView(); 
  45.  } 
  46.  else { 
  47.   ModelMap model = mavContainer.getModel(); 
  48.   HttpStatus status = mavContainer.getStatus(); 
  49.   ModelAndView mav = new ModelAndView(mavContainer.getViewName(), model, status); 
  50.   mav.setViewName(mavContainer.getViewName()); 
  51.   if (!mavContainer.isViewReference()) { 
  52.    mav.setView((View) mavContainer.getView()); 
  53.   } 
  54.   if (model instanceof RedirectAttributes) { 
  55.    Map flashAttributes = ((RedirectAttributes) model).getFlashAttributes(); 
  56.    RequestContextUtils.getOutputFlashMap(request).putAll(flashAttributes); 
  57.   } 
  58.   return mav; 
  59.  } 

这个方法虽然比较长,但是很好理解:

  1. 首先查找到带有 @ExceptionHandler 注解的方法,封装成一个 ServletInvocableHandlerMethod 对象(关于 ServletInvocableHandlerMethod 对象,松哥在之前的文章中已经介绍过了,具体参见:Spring Boot 定义接口的方法是否可以声明为 private?)。
  2. 如果找到了对应的方法,则为 exceptionHandlerMethod 配置参数解析器、视图解析器等,关于这些解析器,参考松哥之前的文章:SpringBoot 中如何自定义参数解析器?、深入分析 SpringMVC 参数解析器、Spring Boot 中如何统一 API 接口响应格式?。
  3. 接下来定义一个 exceptions 数组,如果发生的异常存在异常链,则将整个异常链存入 exceptions 数组中。
  4. exceptions 数组再加上 handlerMethod,共同组成方法参数,调用 exceptionHandlerMethod.invokeAndHandle 完成自定义异常方法的执行,执行结果被保存再 mavContainer 中。
  5. 如果请求到此结束,则直接构造一个 ModelAndView 返回。
  6. 否则从 mavContainer 中取出各项信息,构建新的 ModelAndView 返回。同时,如果存在重定向参数,也将之保存下来(关于重定向参数,参见:SpringMVC 中的参数还能这么传递?涨姿势了!)。

这就是 ExceptionHandlerExceptionResolver 的大致工作流程,可以看到,还是非常 easy 的。

2.2 DefaultHandlerExceptionResolver

这个看名字就知道是一个默认的异常处理器,用来处理一些常见的异常类型,我们来看一下它的 doResolveException 方法:

  1. @Override 
  2. @Nullable 
  3. protected ModelAndView doResolveException( 
  4.   HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) { 
  5.  try { 
  6.   if (ex instanceof HttpRequestMethodNotSupportedException) { 
  7.    return handleHttpRequestMethodNotSupported( 
  8.      (HttpRequestMethodNotSupportedException) ex, request, response, handler); 
  9.   } 
  10.   else if (ex instanceof HttpMediaTypeNotSupportedException) { 
  11.    return handleHttpMediaTypeNotSupported( 
  12.      (HttpMediaTypeNotSupportedException) ex, request, response, handler); 
  13.   } 
  14.   else if (ex instanceof HttpMediaTypeNotAcceptableException) { 
  15.    return handleHttpMediaTypeNotAcceptable( 
  16.      (HttpMediaTypeNotAcceptableException) ex, request, response, handler); 
  17.   } 
  18.   else if (ex instanceof MissingPathVariableException) { 
  19.    return handleMissingPathVariable( 
  20.      (MissingPathVariableException) ex, request, response, handler); 
  21.   } 
  22.   else if (ex instanceof MissingServletRequestParameterException) { 
  23.    return handleMissingServletRequestParameter( 
  24.      (MissingServletRequestParameterException) ex, request, response, handler); 
  25.   } 
  26.   else if (ex instanceof ServletRequestBindingException) { 
  27.    return handleServletRequestBindingException( 
  28.      (ServletRequestBindingException) ex, request, response, handler); 
  29.   } 
  30.   else if (ex instanceof ConversionNotSupportedException) { 
  31.    return handleConversionNotSupported( 
  32.      (ConversionNotSupportedException) ex, request, response, handler); 
  33.   } 
  34.   else if (ex instanceof TypeMismatchException) { 
  35.    return handleTypeMismatch( 
  36.      (TypeMismatchException) ex, request, response, handler); 
  37.   } 
  38.   else if (ex instanceof HttpMessageNotReadableException) { 
  39.    return handleHttpMessageNotReadable( 
  40.      (HttpMessageNotReadableException) ex, request, response, handler); 
  41.   } 
  42.   else if (ex instanceof HttpMessageNotWritableException) { 
  43.    return handleHttpMessageNotWritable( 
  44.      (HttpMessageNotWritableException) ex, request, response, handler); 
  45.   } 
  46.   else if (ex instanceof MethodArgumentNotValidException) { 
  47.    return handleMethodArgumentNotValidException( 
  48.      (MethodArgumentNotValidException) ex, request, response, handler); 
  49.   } 
  50.   else if (ex instanceof MissingServletRequestPartException) { 
  51.    return handleMissingServletRequestPartException( 
  52.      (MissingServletRequestPartException) ex, request, response, handler); 
  53.   } 
  54.   else if (ex instanceof BindException) { 
  55.    return handleBindException((BindException) ex, request, response, handler); 
  56.   } 
  57.   else if (ex instanceof NoHandlerFoundException) { 
  58.    return handleNoHandlerFoundException( 
  59.      (NoHandlerFoundException) ex, request, response, handler); 
  60.   } 
  61.   else if (ex instanceof AsyncRequestTimeoutException) { 
  62.    return handleAsyncRequestTimeoutException( 
  63.      (AsyncRequestTimeoutException) ex, request, response, handler); 
  64.   } 
  65.  } 
  66.  catch (Exception handlerEx) { 
  67.  } 
  68.  return null

可以看到,这里实际上就是根据不同的异常类型,然后调用不同的类去处理该异常。这里相关的处理都比较容易,以 HttpRequestMethodNotSupportedException 为例,异常处理就是对 response 对象做一些配置,如下:

  1. protected ModelAndView handleHttpRequestMethodNotSupported(HttpRequestMethodNotSupportedException ex, 
  2.   HttpServletRequest request, HttpServletResponse response, @Nullable Object handler) throws IOException { 
  3.  String[] supportedMethods = ex.getSupportedMethods(); 
  4.  if (supportedMethods != null) { 
  5.   response.setHeader("Allow", StringUtils.arrayToDelimitedString(supportedMethods, ", ")); 
  6.  } 
  7.  response.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, ex.getMessage()); 
  8.  return new ModelAndView(); 

配置响应头,然后 sendError,最后返回一个空的 ModelAndView 对象。

其实这里哥哥异常处理方法都大同小异,松哥就不再赘述啦。

2.3 ResponseStatusExceptionResolver

这个用来处理 ResponseStatusException 类型的异常,或者使用了 @ResponseStatus 注解标记的普通异常类。我们来看下它的 doResolveException 方法:

  1. @Override 
  2. @Nullable 
  3. protected ModelAndView doResolveException( 
  4.   HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) { 
  5.  try { 
  6.   if (ex instanceof ResponseStatusException) { 
  7.    return resolveResponseStatusException((ResponseStatusException) ex, request, response, handler); 
  8.   } 
  9.   ResponseStatus status = AnnotatedElementUtils.findMergedAnnotation(ex.getClass(), ResponseStatus.class); 
  10.   if (status != null) { 
  11.    return resolveResponseStatus(status, request, response, handler, ex); 
  12.   } 
  13.   if (ex.getCause() instanceof Exception) { 
  14.    return doResolveException(request, response, handler, (Exception) ex.getCause()); 
  15.   } 
  16.  } 
  17.  catch (Exception resolveEx) { 
  18.  } 
  19.  return null

可以看到,首先判断异常类型是不是 ResponseStatusException,如果是,则直接调用 resolveResponseStatusException 方法进行异常信息处理,如果不是,则去查找到异常类上的 @ResponseStatus 注解,并从中查找出相关的异常信息,然后调用 resolveResponseStatus 方法进行处理。

可以看到,ResponseStatusExceptionResolver 处理的异常类型有两种:

  • 直接继承自 ResponseStatusException 的异常类,这种异常类可以直接从里边提取出来想要的信息。
  • 通过 @ResponseStatus 注解的普通异常类,这种情况下异常信息从 @ResponseStatus 注解中提取出来。

这个比较简单,没啥好说的。

2.4 SimpleMappingExceptionResolver

SimpleMappingExceptionResolver 则是根据不同的异常显示不同的 error 页面。可能有的小伙伴还没用过 SimpleMappingExceptionResolver,所以松哥这里先简单说一下用法。

SimpleMappingExceptionResolver 的配置非常简单,直接提供一个 SimpleMappingExceptionResolver 的实例即可,如下:

  1. @Bean 
  2. SimpleMappingExceptionResolver simpleMappingExceptionResolver() { 
  3.     SimpleMappingExceptionResolver resolver = new SimpleMappingExceptionResolver(); 
  4.     Properties mappings = new Properties(); 
  5.     mappings.put("java.lang.ArithmeticException""11"); 
  6.     mappings.put("java.lang.NullPointerException""22"); 
  7.     resolver.setExceptionMappings(mappings); 
  8.     Properties statusCodes = new Properties(); 
  9.     statusCodes.put("11""500"); 
  10.     statusCodes.put("22""500"); 
  11.     resolver.setStatusCodes(statusCodes); 
  12.     return resolver; 

在 mappings 中配置异常和 view 之间的对应关系,要写异常类的全路径,后面的 11、22 则表示视图名称;statusCodes 中配置了视图和响应状态码之间的映射关系。配置完成后,如果我们的项目在运行时抛出了 ArithmeticException 异常,则会展示出 11 视图,如果我们的项目在运行时抛出了 NullPointerException 异常,则会展示出 22 视图。

这是用法,了解了用法之后我们再来看源码,就容易理解了,我们直接来看 doResolveException 方法:

  1. @Override 
  2. @Nullable 
  3. protected ModelAndView doResolveException( 
  4.   HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) { 
  5.  String viewName = determineViewName(ex, request); 
  6.  if (viewName != null) { 
  7.   Integer statusCode = determineStatusCode(request, viewName); 
  8.   if (statusCode != null) { 
  9.    applyStatusCodeIfPossible(request, response, statusCode); 
  10.   } 
  11.   return getModelAndView(viewName, ex, request); 
  12.  } 
  13.  else { 
  14.   return null
  15.  } 
  1. 首先调用 determineViewName 方法确定视图的名称。
  2. 接下来调用 determineStatusCode 查看视图是否有对应的 statusCode。
  3. 调用 applyStatusCodeIfPossible 方法将 statusCode 设置到 response 上,这个方法很简单,不多说。
  4. 调用 getModelAndView 方法构造一个 ModelAndView 对象返回,在构造时,同时设置异常参数,异常的信息的 key 默认就是 exception。

在上面这个过程中,有两个比较长的方法,松哥这里需要和大家额外多说两句。

determineViewName

这个就是根据异常类型找到视图名,我们来看下具体的查找方式:

  1. @Nullable 
  2. protected String determineViewName(Exception ex, HttpServletRequest request) { 
  3.  String viewName = null
  4.  if (this.excludedExceptions != null) { 
  5.   for (Class excludedEx : this.excludedExceptions) { 
  6.    if (excludedEx.equals(ex.getClass())) { 
  7.     return null
  8.    } 
  9.   } 
  10.  } 
  11.  if (this.exceptionMappings != null) { 
  12.   viewName = findMatchingViewName(this.exceptionMappings, ex); 
  13.  } 
  14.  if (viewName == null && this.defaultErrorView != null) { 
  15.   viewName = this.defaultErrorView; 
  16.  } 
  17.  return viewName; 
  1. 如果当前异常包含在 excludedExceptions 中,则直接返回 null(意思是当前异常被忽略处理了,直接按照默认方式来)。
  2. 如果 exceptionMappings 不为 null,则直接调用 findMatchingViewName 方法查找异常对应的视图名(exceptionMappings 变量就是前面我们配置的映射关系),具体的查找方式就是遍历我们前面配置的映射表。
  3. 如果没找到对应的 viewName,并且用户配置了 defaultErrorView,则将 defaultErrorView 赋值给 viewName,并将 viewName 返回。

determineStatusCode

  1. @Nullable 
  2. protected Integer determineStatusCode(HttpServletRequest request, String viewName) { 
  3.  if (this.statusCodes.containsKey(viewName)) { 
  4.   return this.statusCodes.get(viewName); 
  5.  } 
  6.  return this.defaultStatusCode; 

这个就比较容易,直接去 statusCodes 中查看是否有视图对应的状态码,如果有则直接返回,如果没有,就返回一个默认的。

3.HandlerExceptionResolverComposite

最后,还有一个 HandlerExceptionResolverComposite 需要和大家介绍下,这是一个组合的异常处理器,用来代理哪些真正干活的异常处理器。

  1. @Override 
  2. @Nullable 
  3. public ModelAndView resolveException( 
  4.   HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) { 
  5.  if (this.resolvers != null) { 
  6.   for (HandlerExceptionResolver handlerExceptionResolver : this.resolvers) { 
  7.    ModelAndView mav = handlerExceptionResolver.resolveException(request, response, handler, ex); 
  8.    if (mav != null) { 
  9.     return mav; 
  10.    } 
  11.   } 
  12.  } 
  13.  return null

它的 resolveException 方法就比较简单了,这种写法我们已经见到过很多次了,不再赘述。

4.小结

好啦,今天就和大家简单聊一聊 SpringMVC 中的异常处理体系,整体来说并不难,小伙伴们可以仔细品一品。

本文转载自微信公众号「江南一点雨」,可以通过以下二维码关注。转载本文请联系江南一点雨公众号。

 

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

SpringMVC 异常处理体系深入分析

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

SpringMVC 异常处理体系深入分析

SpringMVC 中针对异常问题有一套完整的处理体系,这套体系非常好用,今天松哥就花点时间来和大家聊一聊 SpringMVC 中的异常处理体系,我们把 SpringMVC 中的异常体系从头到尾梳理一下。

SpringMVC异常处理源码分析

今天小编给大家分享一下SpringMVC异常处理源码分析的相关知识点,内容详细,逻辑清晰,相信大部分人都还太了解这方面的知识,所以分享这篇文章给大家参考一下,希望大家阅读完这篇文章后有所收获,下面我们一起来了解一下吧。背景我们的代码中,总是
2023-07-05

Scala异常处理的方法深入分析

Scala是一种多范式的编程语言,支持面向对象和函数式编程。Scala也支持异常处理,即在程序运行过程中发生意外或错误时,采取相应的措施
2023-05-14

SpringMVC的异常处理机制详细分析

DispatcherServlet和任何Servlet一样,需要使用Java配置或web.xml根据Servlet规范进行声明和映射。然后,DispatcherServlet使用Spring配置来发现它在请求映射、视图解析、异常处理等方面所
SpringMVCJava2024-11-30

SpringMVC全局异常处理的示例分析

这篇文章主要介绍SpringMVC全局异常处理的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!全局异常实现方式 Spring MVC 处理异常有 3 种方式1.使用 Spring MVC 提供的简单异常处理器
2023-06-02

SpringMVC异常处理机制与自定义异常处理方式的示例分析

这篇文章主要介绍SpringMVC异常处理机制与自定义异常处理方式的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!提到异常处理,就不得不提HandlerExceptionResolvers,我们的Dispat
2023-06-25

SpringMVC异步处理的示例分析

这篇文章主要介绍SpringMVC异步处理的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!异步处理 demo如果要启用异步返回,需要开启 @EnableAsync。如下的代码中,使用 DeferredResu
2023-06-17

深入浅析java中connection reset 的异常处理

今天就跟大家聊聊有关深入浅析java中connection reset 的异常处理,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。在Java中常看见的几个connection rest
2023-05-31

分析Python异常处理

本篇内容主要讲解“分析Python异常处理”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“分析Python异常处理”吧!  “你不可能总是对的”  甚至计算机也会有失误的时候。当然程序员也不例外,
2023-06-01

深入解析PHP多线程处理异常的技巧

在PHP中,多线程是处理大量任务和提高程序性能的有效方式。然而,多线程也带来了一些挑战,特别是如何处理异常。本文将介绍如何合理使用SEO标签来优化文章,同时提供关于如何在PHP中使用多线程处理异常的教程。引言在PHP编程中,多线程是一种常用的技术,它可以有效
深入解析PHP多线程处理异常的技巧
PHP2024-12-18

PHP魔术方法:深入解析异常处理技巧

PHP魔术方法处理异常教程在PHP中,魔术方法是一种特殊类型的函数,它们不需要显式地调用。这些方法可以自动执行一些操作,例如检查变量的值、设置和获取属性等。然而,如果发生错误,魔术方法可能无法正常工作。因此,了解如何正确处理PHP中的异常是非常重要的。首先,让我
PHP魔术方法:深入解析异常处理技巧
PHP2024-12-19

深入理解python try异常处理机制

深入理解python try异常处理机制#python的try语句有两种风格 #一:种是处理异常(try/except/else) #二:种是无论是否发生异常都将执行最后的代码(try/finally)try/except/else风格 t
2022-06-04

怎么深入了解C++异常处理

本篇文章为大家展示了怎么深入了解C++异常处理,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。基本的异常处理异常处理机制:暂缓问题处理,不在当前函数中处理,在他的调用者中处理(先上车,后补票)什么是异
2023-06-22

编程热搜

  • Python 学习之路 - Python
    一、安装Python34Windows在Python官网(https://www.python.org/downloads/)下载安装包并安装。Python的默认安装路径是:C:\Python34配置环境变量:【右键计算机】--》【属性】-
    Python 学习之路 - Python
  • chatgpt的中文全称是什么
    chatgpt的中文全称是生成型预训练变换模型。ChatGPT是什么ChatGPT是美国人工智能研究实验室OpenAI开发的一种全新聊天机器人模型,它能够通过学习和理解人类的语言来进行对话,还能根据聊天的上下文进行互动,并协助人类完成一系列
    chatgpt的中文全称是什么
  • C/C++中extern函数使用详解
  • C/C++可变参数的使用
    可变参数的使用方法远远不止以下几种,不过在C,C++中使用可变参数时要小心,在使用printf()等函数时传入的参数个数一定不能比前面的格式化字符串中的’%’符号个数少,否则会产生访问越界,运气不好的话还会导致程序崩溃
    C/C++可变参数的使用
  • css样式文件该放在哪里
  • php中数组下标必须是连续的吗
  • Python 3 教程
    Python 3 教程 Python 的 3.0 版本,常被称为 Python 3000,或简称 Py3k。相对于 Python 的早期版本,这是一个较大的升级。为了不带入过多的累赘,Python 3.0 在设计的时候没有考虑向下兼容。 Python
    Python 3 教程
  • Python pip包管理
    一、前言    在Python中, 安装第三方模块是通过 setuptools 这个工具完成的。 Python有两个封装了 setuptools的包管理工具: easy_install  和  pip , 目前官方推荐使用 pip。    
    Python pip包管理
  • ubuntu如何重新编译内核
  • 改善Java代码之慎用java动态编译

目录