Java异常分类与Spring MVC统一处理机制详解

Java异常的分类逻辑

Java中的异常主要分为“检查异常（Checked Exception）”和“非检查异常（Unchecked Exception）”两类。这一设计的核心差异在于编译器是否强制要求处理。

• 检查异常：如 IOException 或 SQLException。这类异常通常与外部环境有关（如网络中断、文件丢失），在大多数情况下是不可避免的。编译器会在编译阶段进行检查，若代码未进行捕获（try-catch）或未声明抛出（throws），则编译无法通过。这督促开发者对可能发生的不可控风险进行防御性处理。
• 非检查异常：多为 RuntimeException 及其子类，如 NullPointerException。这类异常通常由程序逻辑错误导致（如空指针引用、数组越界），理论上通过严谨的代码开发和测试是可以避免的。Java语法不强制要求处理它们，旨在减少样板代码，提高开发效率。

Spring MVC 异常的统一处理方案

在实际开发中，为了保持代码整洁并统一前后端的错误反馈，需要对异常进行集中处理。Spring MVC 提供了多种处理途径，各有优劣。

第1步：使用 SimpleMappingExceptionResolver

这是最简单的配置方式，通过在 spring-mvc.xml 中定义 Bean，将不同的异常映射到特定的视图（如 JSP 页面）。

<!-- 将Controller抛出的异常转到特定视图 -->
<bean class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
  <property name="exceptionMappings">
   <props>
    <!-- 不同异常分开跳转 -->
    <prop key="com.test.MyException1">/error/e1</prop>
    <prop key="com.test.MyException2">/error/e2</prop>
    <!-- 默认错误页 -->
    <prop key="java.lang.Throwable">/error/500</prop>
   </props>
  </property>
</bean>

局限性：该方式本质上是视图转发，仅适用于需要返回 HTML 页面的传统请求。对于 AJAX 异步请求，直接跳转会导致前端无法正确解析 JSON 数据或接收错误的 HTTP 状态码，因此在现代前后端分离架构中已不再推荐使用。

第2步：自定义 HandlerExceptionResolver 接口（推荐）

为了实现更灵活的控制，特别是支持 AJAX 请求返回 JSON 数据，建议实现 HandlerExceptionResolver 接口。这种方式不仅能区分普通请求和异步请求，还能方便地集成日志监控等扩展功能。

以下是一个完整的示例，展示了如何检测 AJAX 请求并返回统一的 JSON 结构：

public class MyExceptionHandler implements HandlerExceptionResolver {
 
    public ModelAndView resolveException(HttpServletRequest request,
            HttpServletResponse response, Object handler, Exception ex) {
        
        /* 1. 区分是否为 Ajax 请求 */
        boolean isAjax = request.getHeader("X-Requested-With") != null
                && "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));
        
        if (!isAjax) {
            // 如果是普通请求，跳转到错误页面
            if (ex instanceof com.test.MyException1) {
                return new ModelAndView("/error/e1");
            } else {
                return new ModelAndView("/error/500");
            }
        }
        
        // 2. 针对 Ajax 请求，返回 JSON 数据
        try {
            // 设置字符编码
            request.setCharacterEncoding("utf-8");
            response.setContentType("text/plain;charset=utf-8");
            
            PrintWriter out = response.getWriter();
            // 组装自定义的错误信息结构，便于前端对接
            String jsonRes = "{\"message\":\"" + ex.getMessage() + "\"}";
            out.print(jsonRes);
            out.flush();
        } catch (IOException e) {
            e.printStackTrace();
        }
        
        // 返回 null 表示当前处理器已完全处理该异常，无需继续传播
        return null;
    }
}

随后，在 spring-mvc.xml 中注册该 Bean：

<bean id="exceptionHandler" class="com.test.MyExceptionHandler"/>

优势：通过判断 X-Requested-With 头部，可以完美适配 AJAX 请求；同时在内存中即可完成逻辑处理，性能更好且扩展性强。

第3步：使用 @ExceptionHandler 注解

这是一种基于方法的局部异常处理方式，常用于 Controller 层。

@Controller
public class TestExceptionHandlerController {
 
    @ExceptionHandler({ MyException1.class })
    public String exception(MyException1 e) {
        return "/error/e1";
    }
    
    @RequestMapping("/marry")
    public void test() {
        throw new MyException1("没钱！");
    }
}

局限性与建议：@ExceptionHandler 定义的方法必须位于发生异常的同一个 Controller 类中。这意味着如果多个 Controller 都需要处理同一种异常，代码会产生大量冗余，不利于统一管理。因此，在生产环境中，除非业务逻辑非常特定，否则不建议将其作为主要的统一异常处理手段。

容器与框架的处理协作

在 Web 应用的生命周期中，Tomcat 等容器与 Spring MVC 框架共同构成了异常处理的层级。通常的建议是将 HTTP 级别的状态码（如 404 Not Found）交给容器处理，而具体的业务异常交由 Spring MVC 框架拦截。因为某些异常可能在到达框架之前已经被容器捕获，或者框架层面已经完成了处理并返回了结果，容器便会尊重框架的输出，不再进行二次映射。

以上就是 Java 异常分类及 Spring MVC 统一处理的详细内容，更多关于 Java 后端开发的资料请关注本站其它相关文章！