捕获Exception基类的问题探讨：以Web服务处理场景为例

不少开发规范都明确要求绝对不应捕获基类Exception，而是需要精准定位try块中可能抛出的所有具体异常子类，针对性进行捕获处理。但在Web服务的请求处理场景中，这种规范要求存在实际落地的痛点，以下结合具体代码场景说明为何捕获基类Exception更具合理性，并提出两个核心问题。

场景示例：Web服务请求处理器 #

捕获基类Exception的实现 #

这种写法中，try块执行常规业务逻辑，成功则返回200响应；catch块捕获所有异常，统一返回400错误响应并记录日志：

handleWebRequest( request,  response ) {
    try {
        method1();
        method2();
        method3();
        response.writeResponse(200, responseObject);
    }
    catch (Exception e) {
        response.writeResponse(400, formErrorObject(e));
        logError(e);
    }
}

规范要求的具体异常捕获实现 #

按照规范，需要明确捕获所有可能出现的具体异常（包括不会出现在方法签名中的RuntimeException）：

handleWebRequest( request,  response ) {
    try {
        method1();
        method2();
        method3();
        response.writeResponse(200, responseObject);
    }
    catch (Exception1|Exception2|Exception3|RuntimeException e) {
        response.writeResponse(400, formErrorObject(e));
        logError(e);
    }
}

规范写法的痛点 #

如果后续method2新增抛出Exception2a类型的异常，按照规范要求，所有调用method2的catch块都需要同步更新。一旦遗漏修改，未被捕获的异常会直接导致服务无法返回预期的错误响应，且编译器不会给出任何警告，极易引发线上问题。

而捕获基类Exception的写法，能够自动适配新增的异常类型，确保无论出现何种异常，服务都能返回错误响应，避免出现无响应的情况。

核心问题 #

1. 在此Web服务处理场景下，捕获Exception基类会造成何种危害？
2. 哪些异常在此场景下被捕获会产生不良影响？

内容的提问来源于stack exchange，提问作者AgilePro