网站建设倒计时代码推广计划方案

前面讲过了DispatcherServlet的初始化过程（源码角度的DispatcherServlet的具体初始化过程还没说，先放一放），今天说一下DispatcherServlet处理请求的过程。

处理过程

1. WebApplicationContext绑定在当前request属性上（属性键值DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE）
2. localResolver绑定在request的属性上（属性键值LOCALE_RESOLVER_ATTRIBUTE）
3. themeResolver绑定在request属性上（属性键值HEME_RESOLVER_ATTRIBUTE）
4. servlet容器配置了multipart resolver，并且当前请求包含multpart file，则包装当前request为MultipartHttpServletRequest。
5. 匹配当前请求的handlerMappings，获取到HandlerExecutionChain，匹配getHandlerAdapter
6. 调用HandlerExecutionChain的applyPreHandle方法：获取拦截器，调用拦截器的preHandle方法
7. 调用HandlerAdapter的handle方法，这儿会匹配并执行Conroller方法
8. 执行HandlerExecutionChain的applyPostHandle方法：调用拦截器的postHandle方法
9. 执行processDispatchResult方法，其中会调用拦截器的afterCompletion方法

以上过程都被try catch包围起来了，所以才会有Spring MVC的异常处理机制：应用层不管哪里（controller、service、dao层…）抛出的异常，都会在这里被捕获到，注册到WebApplicationContext容器中的HandlerExceptionResolver beans就有机会统一处理异常。

可以通过DispatcherServlet的初始化参数来定制化其行为，参数可以通过web.xml指定，包括：

1. contextClass：指定当前DispatcherServlet绑定的容器类（ConfigurableWebApplicationContext的实现类），默认为XmlWebApplicationContext 。
2. contextConfigLocation:上述contextClass指定的容器类的配置文件的位置，可以指定多个配置文件，逗号分割。
3. namespace：WebApplicationContext的namespace，默认[servlet-name]-servlet。
4. throwExceptionIfNoHandlerFound：某一请求request没有匹配到handle的话，是否抛出NoHandlerFoundException异常，NoHandlerFoundException随后可以被HandlerExceptionResolver捕获并处理。默认情况下该参数设置为false，DispatherServlet不抛出异常、直接导航到404。注意：如果配置了默认Servlet Handler(default servlet handling)的话，那么没匹配到的request会导航到默认handler处理，永远不会出现404。

拦截

HandlerMapping支持拦截器，拦截器需实现SpringMVC的HandlerInterceptor接口（org.springframework.web.servlet），包含如下方法：

1. preHandle：HandlerMapping处理请求之前发生。
2. postHandle：HandlerMapping处理请求之后发生。
3. afterCompletion：整个请求处理完成之后。

preHandle返回true则请求继续被处理，返回false则后续不会再处理请求。

postHandle对@ResponseBody和ResponseEntity方法几乎没有什么作用，因为response已经在postHandle之前被HandlerAdapter处理完成了，因此不可能被postHandle修改了。比如你想通过postHandle在response header中增加一个头信息是不可能的了。这种需求只能通过ResponseBodyAdvice、 Controller Advice 或者直接在RequestMappingHandlerAdapter中直接实现。

异常处理

HandleMapping、HandlerAdapter、Controller中发生的任何异常，都可以被DispatcherServlet捕获、交给HandlerExceptionResolver bean去处理异常。

SpringMVC提供如下异常处理的实现类：

异常处理链
我们可以配置多个HandlerExceptionResolver作为异常处理链（exception resolver chain）来处理异常，可以通过order属性指定其处理顺序，order值越大、在chain中排名越靠后。

HandlerExceptionResolver可以返回：

1. ModelAndView ：错误页面。
2. 空ModelAndView：错误已经被处理，不需要导航到错误页面。
3. Null：当前Resolver不处理，异常继续向上抛给chain中后面的Resolver，直到最后如果没有Resolver处理该异常的话，异常会抛出给Servlet容器（比如给到Tomcat，这种情况下Tomcat也不处理，可能就会直接抛出给前台）。

SpringMVC会自动配置内建的异常处理器，我们可以通过配置客户化异常处理器。SpringMVC的异常处理相对比较重要，后面我们还会从源码和应用角度做一次分析。

容器错误页面

如果异常没有被任何HandlerExceptionResolver处理，而且，如果response status被设置为4xx、5xx的话，servlet容器（比如tomcat）会导航到默认的错误处理页面，假如容器配置了错误处理页面的话。可以通过web.xml配置：

<error-page><location>/error</location>
</error-page>

以上配置需要DispatcherServlet进一步处理：

@RestController
public class ErrorController {@RequestMapping(path = "/error")public Map<String, Object> handle(HttpServletRequest request) {Map<String, Object> map = new HashMap<>();map.put("status", request.getAttribute("jakarta.servlet.error.status_code"));map.put("reason", request.getAttribute("jakarta.servlet.error.message"));return map;}
}

上一篇 Spring MVC 五 - DispatcherServlet初始化过程（续）