在Controller的请求处理方法中手动使用try…catch块捕捉异常，当捕捉到指定的异常时，系统返回对应的逻辑视图名——但这种异常处理方式非常烦琐，需要在请求处理方法中书写大量的catch块。其最大的缺点还在于异常处理与代码耦合，一旦需要改变异常处理方式，必须修改大量的代码！这是一种相当糟糕的方式。
对于MVC框架，希望其提供的异常处理流程

异常处理流程是，当控制器的处理方法处理用户请求时，如果出现了异常1，则系统转入视图资源1，并在该视图资源上输出异常提示；如果出现异常2，则系统转入视图资源2，并在该视图资源上输出异常提示。

假如在控制器的处理方法中使用try…catch块来捕捉异常，当捕捉到指定的异常时，系统返回对应的逻辑视图名——这种处理方式完全是手动处理异常，非常烦琐，而且可维护性不好：如果有一天需要改变异常处理流程，则必须修改控制器的代码。

如果手动捕捉（catch）异常，然后返回（return）一个字符串作为逻辑视图名，其实质就是定义异常类与逻辑视图名之间的对应关系。既然如此，那么完全可以将这种对应关系放在配置文件中进行管理。实际上，早期Spring MVC确实是这么干的——那时候Spring MVC主要还是受Struts 2的影响。

Spring MVC异常处理机制

主要由HandlerExceptionResolver接口负责处理，该接口中只定义了如下抽象方法：

看这个方法的参数和返回值，是不是一切全明白了？
该方法包含4个参数，其中request、response参数不用管，毕竟处理Web请求总离不开这些Servlet API；handler代表抛出异常的处理方法；Exception ex是关键参数，其返回值是ModelAndView——该异常解析器做的事情是什么？不就是完成Exception类与ModelAndView的对应关系吗？
Spring MVC为HandlerExceptionResolver接口提供的实现类如图

HandlerExceptionResolver的实现类

有如下几个。
➢ SimpleMappingExceptionResolver：这是Spring MVC刚出现时提供的实现类，完全是模仿Struts 2的一个实现类，现在一般不推荐使用它。
➢ DefaultHandlerExceptionResolver：它是Spring MVC默认的异常解析器。

➢ ResponseStatusExceptionResolver：它负责为＠ResponseStatus注解修饰的异常类提供底层支持。
➢ ExceptionHandlerExceptionResolver：它负责为＠ExceptionHandler注解修饰的异常处理方法提供底层支持。
➢ HandlerExceptionResolverComposite：它是一系列异常解析器的前端代理。

随着Spring 1.0面世的Spring MVC，难免受到Struts 2的影响，因此HandlerExceptionResolver只有一个实现类：SimpleMappingExceptionResolver，它的设计哲学完全模仿Struts 2：在配置文件中定义异常类与逻辑视图名之间的对应关系。

如果Spring MVC一直停留在“模仿Struts 2”的层次，那么就不会有今天Spring MVC的辉煌了。

伴随着Spring 3的“王者归来”，Spring MVC带来了“颠覆式”的异常处理机制，它彻底脱离了Struts 2的窠臼，改为基于AOP的异常处理机制。这种异常处理机制不仅能定义异常类与逻辑视图名之间的对应关系，还可对异常做一些额外的修复处理，并彻底将异常处理代码与业务处理代码分离。这种异常处理机制的底层由ResponseStatusExceptionResolver、ExceptionHandlerExceptionResolver等实现类提供支持；而开发者使用＠ResponseStatus、＠ExceptionHandler、＠ControllerAdvice注解，以声明式方式进行异常处理即可。

至于

DefaultHandlerExceptionResolver实现类

，它是Spring MVC内置的异常解析类，定义了常见异常类与HTTP状态码之间的对应关系。比如MissingPathVariableException异常类，对应500（SC_INTERNAL_SERVER_ERROR）、TypeMismatchException异常类对应400（SC_BAD_REQUEST）……关于该类支持的异常类与HTTP状态码之间的对应关系，读者可自行参看该类的API文档。

DefaultHandlerExceptionResolver类只能支持这些异常类，因为它的源代码就是在doResolveException()方法中以“硬编码”方式写死了这些异常类与HTTP状态码之间的对应关系的——读者可自行查看这个实现类的源代码。

DefaultHandlerExceptionResolver

是Spring MVC框架本身使用的异常解析器，开发者一般不会直接用到它。
总结：Spring MVC的异常处理机制无非两类。
➢ 使用SimpleMappingExceptionResolver，基于配置文件的异常处理机制。这种机制完全类似于Struts 2的异常处理机制。

➢ 使用＠ResponseStatus、＠ExceptionHandler、＠ControllerAdvice，基于AOP的异常处理机制。这是目前主流的异常处理机制。
本节将会简单介绍使用SimpleMappingExceptionResolver的传统的异常处理机制，重点还是以使用＠ResponseStatus、＠ExceptionHandler、＠ControllerAdvice的异常处理机制为主。