Java异常处理最佳实践与设计模式深度探讨

在Java开发中，异常处理是保障程序稳定性、可维护性和可读性的核心环节之一。不合理的异常处理会导致程序崩溃、调试困难、代码冗余，甚至隐藏潜在的业务风险；而规范的异常处理的不仅能优雅地应对程序异常，还能提升代码的健壮性和可扩展性。本文将从Java异常的基础认知出发，深入探讨异常处理的最佳实践，结合常见设计模式拆解落地方案，搭配实战案例说明如何在项目中高效运用，帮助开发者跳出异常处理的误区，构建更可靠的Java应用。

一、Java异常基础回顾（核心认知铺垫）

在探讨最佳实践和设计模式之前，我们先简要回顾Java异常的核心体系，明确异常的分类与本质，为后续内容奠定基础。

1.1 异常体系结构

Java异常体系以Throwable为顶层父类，分为两大子类：Error和Exception，二者的职责与处理方式截然不同，需严格区分。

Error ：虚拟机级别的严重错误，属于不可恢复的异常，开发者无需捕获也无法处理（如OutOfMemoryError、StackOverflowError）。这类异常通常由虚拟机抛出，代表程序运行环境出现致命问题，此时程序应终止运行，而非强行捕获。
Exception：程序运行过程中可预期、可处理的异常，是异常处理的核心对象，分为两类：
- 受检异常（Checked Exception）：编译期强制要求捕获或声明抛出的异常（如IOException、SQLException），通常对应外部资源访问、网络请求等可预见的异常场景。
- 非受检异常（Unchecked Exception）：编译期不强制捕获，继承自RuntimeException（如NullPointerException、IndexOutOfBoundsException），通常由代码逻辑错误导致，应通过规范代码逻辑避免，而非过度捕获。

1.2 异常处理的核心目标

异常处理的本质不是"消灭异常"，而是"优雅地应对异常"，其核心目标包括三点：

避免程序非预期崩溃，保障程序正常运行或优雅降级；
提供清晰、准确的异常信息，便于开发者快速定位问题；
降低异常处理代码的冗余度，提升代码的可维护性和可读性。

二、Java异常处理最佳实践（避坑指南）

结合实际开发场景，我们总结了8条异常处理最佳实践，覆盖异常捕获、抛出、信息封装等核心环节，帮助开发者规避常见误区。

2.1 精准捕获异常，避免"大而全"的捕获

误区：使用catch (Exception e)捕获所有异常，导致无法区分具体异常类型，隐藏了真正的问题（如将NullPointerException与IOException同等处理）。

最佳实践：精准捕获具体异常类型，多个异常类型可使用多catch块，按"子类在前、父类在后"的顺序排列（避免父类异常屏蔽子类异常）。

java 复制代码

// 错误示例：大而全的异常捕获
try {
    // 读取文件
    FileReader reader = new FileReader("test.txt");
    reader.read();
} catch (Exception e) {
    // 无法区分是文件不存在、权限不足还是其他异常
    e.printStackTrace();
}

// 正确示例：精准捕获具体异常
try {
    FileReader reader = new FileReader("test.txt");
    reader.read();
} catch (FileNotFoundException e) {
    // 明确处理"文件不存在"异常（如提示用户检查路径）
    log.error("文件不存在，请检查文件路径：{}", "test.txt", e);
} catch (IOException e) {
    // 处理文件读取异常（如重试、关闭资源）
    log.error("文件读取失败", e);
}

2.2 避免空catch块，异常不可"视而不见"

误区：捕获异常后不做任何处理（空catch块），导致异常被隐藏，程序出现异常时无法定位问题，甚至引发更严重的连锁反应。

最佳实践：任何异常都需有处理逻辑，即使是"可忽略"的异常，也应记录日志（便于后续排查），或根据业务场景做降级处理。

java 复制代码

// 错误示例：空catch块
try {
    // 尝试解析字符串为数字
    Integer.parseInt("abc");
} catch (NumberFormatException e) {
    // 不做任何处理，异常被隐藏
}

// 正确示例：记录日志+业务降级
try {
    Integer.parseInt("abc");
} catch (NumberFormatException e) {
    log.warn("字符串解析为数字失败，输入值：{}", "abc", e);
    // 业务降级：返回默认值
    return 0;
}

2.3 使用try-with-resources自动关闭资源

误区：手动关闭文件、流、数据库连接等资源时，在finally块中编写关闭逻辑，容易出现代码冗余，且可能因异常嵌套导致资源泄漏。

最佳实践：Java 7及以上提供的try-with-resources语法，可自动关闭实现AutoCloseable接口的资源（如InputStream、Connection），简化代码并避免资源泄漏。

java 复制代码

// 错误示例：手动关闭资源，代码冗余且易泄漏
FileReader reader = null;
try {
    reader = new FileReader("test.txt");
    reader.read();
} catch (IOException e) {
    log.error("文件读取失败", e);
} finally {
    // 需判断资源是否为空，避免空指针
    if (reader != null) {
        try {
            reader.close();
        } catch (IOException e) {
            log.error("文件关闭失败", e);
        }
    }
}

// 正确示例：try-with-resources自动关闭资源
try (FileReader reader = new FileReader("test.txt")) {
    reader.read();
} catch (IOException e) {
    log.error("文件读取或关闭失败", e);
}

2.4 异常信息需具体，避免模糊表述

误区：异常日志仅记录"异常发生了"，未包含关键上下文信息（如输入参数、业务场景），导致排查问题时无从下手。

最佳实践：异常日志需包含"场景+上下文+异常栈" ，使用日志框架（如SLF4J+Logback）记录，避免使用e.printStackTrace()（日志输出位置混乱，且可能泄露敏感信息）。

java 复制代码

// 错误示例：日志模糊，无上下文
try {
    String userId = null;
    getUserInfo(userId);
} catch (NullPointerException e) {
    log.error("空指针异常"); // 无上下文，无法定位哪里为空
}

// 正确示例：日志包含上下文信息
try {
    String userId = null;
    getUserInfo(userId);
} catch (NullPointerException e) {
    // 记录场景（获取用户信息）、上下文（userId为空）、异常栈
    log.error("获取用户信息失败，userId：{}，原因：空指针异常", userId, e);
}

2.5 合理区分受检与非受检异常，不滥用受检异常

误区：将所有异常都定义为受检异常，导致方法签名中频繁出现throws，增加调用者的负担；或反之，将所有异常都定义为非受检异常，导致异常未被及时处理。

最佳实践：

使用受检异常：对应"可预期、可恢复"的异常场景（如文件不存在、数据库连接失败），强制调用者处理，避免遗漏。
使用非受检异常：对应"代码逻辑错误"（如空指针、数组越界），无需强制捕获，通过规范代码逻辑（如判空、校验参数）避免。

2.6 异常链的正确使用，保留原始异常信息

误区：捕获异常后，直接抛出新异常，未保留原始异常栈，导致排查问题时丢失根源信息。

最佳实践：使用异常链，在抛出新异常时，将原始异常作为构造参数传入，保留完整的异常栈轨迹（便于追溯问题根源）。

java 复制代码

// 错误示例：丢失原始异常信息
public void getUserInfo(String userId) throws BusinessException {
    try {
        // 调用数据库查询
        jdbcTemplate.queryForObject("select * from user where id = ?", userId);
    } catch (SQLException e) {
        // 抛出新异常，但未保留原始SQLException栈
        throw new BusinessException("获取用户信息失败");
    }
}

// 正确示例：使用异常链，保留原始异常
public void getUserInfo(String userId) throws BusinessException {
    try {
        jdbcTemplate.queryForObject("select * from user where id = ?", userId);
    } catch (SQLException e) {
        // 将原始SQLException作为构造参数传入，保留异常链
        throw new BusinessException("获取用户信息失败，userId：" + userId, e);
    }
}

2.7 不使用异常控制程序流程

误区：将异常作为"条件判断"的替代方案，用try-catch控制程序的执行流程（如判断文件是否存在时，通过捕获FileNotFoundException来处理），导致代码可读性差、性能损耗。

最佳实践：异常仅用于处理"非预期异常场景" ，正常的条件判断应使用普通的if-else逻辑。

java 复制代码

// 错误示例：用异常控制程序流程
try {
    File file = new File("test.txt");
    FileReader reader = new FileReader(file);
    // 若文件存在，执行读取逻辑
} catch (FileNotFoundException e) {
    // 若文件不存在，执行创建逻辑
    file.createNewFile();
}

// 正确示例：用if-else判断，异常仅处理意外情况
File file = new File("test.txt");
if (file.exists()) {
    try (FileReader reader = new FileReader(file)) {
        reader.read();
    } catch (IOException e) {
        log.error("文件读取失败", e);
    }
} else {
    try {
        file.createNewFile();
    } catch (IOException e) {
        log.error("文件创建失败", e);
    }
}

2.8 自定义异常需规范，避免过度定义

误区：自定义异常过多（如每个业务场景都定义一个异常），或自定义异常未包含业务编码、描述等关键信息，导致异常管理混乱。

最佳实践：自定义异常应按业务模块分类 ，包含业务编码（便于前端提示）、异常描述，继承自Exception（受检）或RuntimeException（非受检），避免继承顶层Throwable。

java 复制代码

// 规范的自定义业务异常
public class BusinessException extends RuntimeException {
    // 业务异常编码（如：USER_NOT_FOUND=10001）
    private final String code;
    
    // 构造方法：支持异常链
    public BusinessException(String code, String message) {
        super(message);
        this.code = code;
    }
    
    public BusinessException(String code, String message, Throwable cause) {
        super(message, cause);
        this.code = code;
    }
    
    // getter方法
    public String getCode() {
        return code;
    }
}

// 使用示例
if (user == null) {
    throw new BusinessException("10001", "用户不存在，userId：" + userId);
}

三、异常处理常用设计模式（落地方案）

在复杂项目中，仅依靠基础的异常处理语法难以满足"高内聚、低耦合"的需求。结合设计模式，可将异常处理逻辑抽象、复用，提升代码的可维护性。以下是5种最常用的异常处理设计模式，搭配实战场景说明。

3.1 异常封装模式（Exception Wrapping）

核心思想

将底层异常（如SQLException、IOException）封装为上层业务异常（如BusinessException），隐藏底层实现细节，同时保留原始异常信息，实现"底层异常隔离"与"上层业务统一处理"。

适用场景

多层架构项目（如Controller-Service-Dao），Dao层抛出的底层异常（如数据库异常），不应直接抛到Controller层，需封装为业务异常，便于上层统一处理（如返回统一的错误响应）。

实战示例

java 复制代码

// 1. Dao层：抛出底层SQLException
@Repository
public class UserDao {
    public User selectById(String userId) throws SQLException {
        String sql = "select * from user where id = ?";
        return jdbcTemplate.queryForObject(sql, new Object[]{userId}, new BeanPropertyRowMapper<>(User.class));
    }
}

// 2. Service层：封装底层异常为业务异常
@Service
public class UserService {
    @Autowired
    private UserDao userDao;
    
    public User getUserInfo(String userId) {
        try {
            return userDao.selectById(userId);
        } catch (SQLException e) {
            // 封装底层异常为业务异常，保留异常链
            throw new BusinessException("20001", "查询用户数据库失败，userId：" + userId, e);
        }
    }
}

// 3. Controller层：统一捕获业务异常，返回统一响应
@RestController
@RequestMapping("/user")
public class UserController {
    @Autowired
    private UserService userService;
    
    @GetMapping("/{userId}")
    public Result<User> getUser(@PathVariable String userId) {
        try {
            User user = userService.getUserInfo(userId);
            return Result.success(user);
        } catch (BusinessException e) {
            // 统一返回错误响应（包含业务编码和描述）
            return Result.error(e.getCode(), e.getMessage());
        }
    }
}

3.2 异常转译模式（Exception Translation）

核心思想

与异常封装类似，但更侧重"异常类型的转换"------将一种类型的异常转译为另一种更贴合当前场景的异常，解决"底层异常与上层业务场景不匹配"的问题。Spring框架的JdbcTemplate就是典型的异常转译实现。

适用场景

第三方框架或底层API抛出的异常，与当前业务场景无关，需转译为业务相关的异常（如将SQLException转译为DataAccessException）。

实战示例（模拟Spring异常转译）

java 复制代码

// 1. 定义数据访问相关的统一异常
public class DataAccessException extends RuntimeException {
    public DataAccessException(String message, Throwable cause) {
        super(message, cause);
    }
}

// 2. 异常转译工具类（将SQLException转译为DataAccessException）
public class ExceptionTranslator {
    // 转译异常：根据不同的SQLException子类，返回不同的业务异常
    public static DataAccessException translate(SQLException e) {
        if (e instanceof SQLSyntaxErrorException) {
            return new DataAccessException("SQL语法错误：" + e.getMessage(), e);
        } else if (e instanceof SQLTimeoutException) {
            return new DataAccessException("数据库查询超时", e);
        } else {
            return new DataAccessException("数据库访问失败", e);
        }
    }
}

// 3. 使用转译工具类
public class UserDao {
    public User selectById(String userId) {
        try {
            String sql = "select * from user where id = ?";
            return jdbcTemplate.queryForObject(sql, new Object[]{userId}, new BeanPropertyRowMapper<>(User.class));
        } catch (SQLException e) {
            // 转译底层异常
            throw ExceptionTranslator.translate(e);
        }
    }
}

3.3 策略模式（异常处理策略）

核心思想

将不同的异常处理逻辑抽象为"策略"，根据异常类型或业务场景，动态选择对应的处理策略，实现"异常处理逻辑与业务逻辑解耦"，便于扩展新的异常处理方式。

适用场景

同一类型的异常，在不同业务场景下需要不同的处理方式（如：数据库超时异常，在查询场景下重试，在提交场景下回滚）。

实战示例

java 复制代码

// 1. 定义异常处理策略接口
public interface ExceptionHandlerStrategy {
    // 处理异常的方法
    void handle(Exception e);
}

// 2. 实现不同的处理策略
// 策略1：重试策略（适用于查询场景）
public class RetryExceptionHandler implements ExceptionHandlerStrategy {
    private int retryCount = 3; // 重试次数
    private long retryInterval = 1000; // 重试间隔（毫秒）
    
    @Override
    public void handle(Exception e) {
        for (int i = 0; i < retryCount; i++) {
            try {
                log.warn("异常重试，第{}次，异常信息：{}", i+1, e.getMessage());
                Thread.sleep(retryInterval);
                // 重新执行业务逻辑（此处可通过回调函数传入）
                return;
            } catch (InterruptedException ex) {
                Thread.currentThread().interrupt();
            } catch (Exception ex) {
                if (i == retryCount - 1) {
                    log.error("重试次数耗尽，异常处理失败", ex);
                }
            }
        }
    }
}

// 策略2：回滚策略（适用于提交场景）
public class RollbackExceptionHandler implements ExceptionHandlerStrategy {
    @Override
    public void handle(Exception e) {
        log.error("执行回滚操作，异常信息：{}", e.getMessage(), e);
        // 执行事务回滚逻辑
        TransactionSynchronizationManager.getCurrentTransactionStatus().setRollbackOnly();
    }
}

// 3. 策略工厂（根据场景获取对应的策略）
public class ExceptionHandlerFactory {
    public static ExceptionHandlerStrategy getStrategy(String scene) {
        switch (scene) {
            case "query":
                return new RetryExceptionHandler();
            case "commit":
                return new RollbackExceptionHandler();
            default:
                throw new IllegalArgumentException("不支持的异常处理场景：" + scene);
        }
    }
}

// 4. 使用策略模式处理异常
public class OrderService {
    public void submitOrder(Order order) {
        try {
            // 执行订单提交逻辑（可能抛出数据库超时异常）
            orderDao.insert(order);
        } catch (SQLTimeoutException e) {
            // 根据业务场景（提交场景）获取策略，处理异常
            ExceptionHandlerStrategy strategy = ExceptionHandlerFactory.getStrategy("commit");
            strategy.handle(e);
        }
    }
    
    public Order queryOrder(String orderId) {
        try {
            return orderDao.selectById(orderId);
        } catch (SQLTimeoutException e) {
            // 根据业务场景（查询场景）获取策略，处理异常
            ExceptionHandlerStrategy strategy = ExceptionHandlerFactory.getStrategy("query");
            strategy.handle(e);
            return null;
        }
    }
}

3.4 装饰器模式（异常增强处理）

核心思想

在不修改原有异常处理逻辑的基础上，通过"装饰器"对异常处理过程进行增强（如：添加日志记录、异常统计、告警通知等），实现"单一职责"原则。

适用场景

需要对现有异常处理逻辑进行扩展，且不希望修改原有代码（如：所有异常处理完成后，添加告警通知）。

实战示例

java 复制代码

// 1. 原有异常处理接口（核心逻辑）
public interface ExceptionHandler {
    void handle(Exception e);
}

// 2. 原有异常处理实现（仅记录日志）
public class LogExceptionHandler implements ExceptionHandler {
    @Override
    public void handle(Exception e) {
        log.error("异常处理：{}", e.getMessage(), e);
    }
}

// 3. 装饰器1：添加告警通知增强
public class AlarmExceptionHandlerDecorator implements ExceptionHandler {
    private final ExceptionHandler delegate; // 被装饰的对象
    
    public AlarmExceptionHandlerDecorator(ExceptionHandler delegate) {
        this.delegate = delegate;
    }
    
    @Override
    public void handle(Exception e) {
        // 先执行原有逻辑（记录日志）
        delegate.handle(e);
        // 增强逻辑：发送告警通知（如短信、钉钉）
        sendAlarm(e);
    }
    
    private void sendAlarm(Exception e) {
        log.warn("发送告警通知，异常信息：{}", e.getMessage());
        // 告警通知逻辑（调用第三方告警接口）
    }
}

// 4. 装饰器2：添加异常统计增强
public class StatExceptionHandlerDecorator implements ExceptionHandler {
    private final ExceptionHandler delegate;
    private final Counter exceptionCounter; // 异常计数器（如Prometheus计数器）
    
    public StatExceptionHandlerDecorator(ExceptionHandler delegate, Counter exceptionCounter) {
        this.delegate = delegate;
        this.exceptionCounter = exceptionCounter;
    }
    
    @Override
    public void handle(Exception e) {
        // 增强逻辑：统计异常次数
        exceptionCounter.increment();
        // 执行原有逻辑
        delegate.handle(e);
    }
}

// 5. 使用装饰器增强异常处理
public class Test {
    public static void main(String[] args) {
        // 1. 初始化原有异常处理器
        ExceptionHandler logHandler = new LogExceptionHandler();
        
        // 2. 装饰：添加告警功能
        ExceptionHandler alarmHandler = new AlarmExceptionHandlerDecorator(logHandler);
        
        // 3. 装饰：添加统计功能
        Counter exceptionCounter = Counter.build("java_exception_total", "异常总数").register();
        ExceptionHandler finalHandler = new StatExceptionHandlerDecorator(alarmHandler, exceptionCounter);
        
        // 4. 处理异常（同时执行日志、告警、统计）
        finalHandler.handle(new NullPointerException("测试异常"));
    }
}

3.5 模板方法模式（统一异常处理模板）

核心思想

定义异常处理的"固定流程模板"（如：前置校验→执行业务→异常捕获→异常处理→后置清理），将可变的异常处理逻辑抽象为抽象方法，由子类实现，实现"流程统一、逻辑可扩展"。

适用场景

多个业务模块的异常处理流程一致，仅具体的异常处理逻辑不同（如：所有接口的异常处理都需要"记录日志→返回统一响应"，仅响应信息不同）。

实战示例（统一接口异常处理模板）

java 复制代码

// 1. 定义异常处理模板类（抽象类）
public abstract class AbstractExceptionHandlerTemplate {
    // 固定模板流程（不可修改）
    public final Result<?> handle(Exception e) {
        // 步骤1：前置处理（统一记录日志）
        preHandle(e);
        
        // 步骤2：核心异常处理（可变逻辑，由子类实现）
        Result<?> result = doHandle(e);
        
        // 步骤3：后置处理（统一清理、统计）
        postHandle(e);
        
        return result;
    }
    
    // 前置处理：统一记录日志（固定逻辑）
    private void preHandle(Exception e) {
        log.error("接口异常，异常信息：{}", e.getMessage(), e);
    }
    
    // 核心处理：可变逻辑，由子类实现
    protected abstract Result<?> doHandle(Exception e);
    
    // 后置处理：统一统计（固定逻辑）
    private void postHandle(Exception e) {
        // 异常统计逻辑
        ExceptionStatistic.increment();
    }
}

// 2. 实现业务异常处理子类
public class BusinessExceptionHandler extends AbstractExceptionHandlerTemplate {
    @Override
    protected Result<?> doHandle(Exception e) {
        // 处理业务异常，返回业务编码和描述
        BusinessException businessException = (BusinessException) e;
        return Result.error(businessException.getCode(), businessException.getMessage());
    }
}

// 3. 实现系统异常处理子类
public class SystemExceptionHandler extends AbstractExceptionHandlerTemplate {
    @Override
    protected Result<?> doHandle(Exception e) {
        // 处理系统异常（如空指针、超时），返回统一的系统错误信息
        return Result.error("99999", "系统异常，请联系管理员");
    }
}

// 4. 使用模板处理异常
@RestControllerAdvice // 全局异常处理器
public class GlobalExceptionHandler {
    @Autowired
    private BusinessExceptionHandler businessExceptionHandler;
    @Autowired
    private SystemExceptionHandler systemExceptionHandler;
    
    // 捕获业务异常
    @ExceptionHandler(BusinessException.class)
    public Result<?> handleBusinessException(BusinessException e) {
        return businessExceptionHandler.handle(e);
    }
    
    // 捕获系统异常
    @ExceptionHandler(RuntimeException.class)
    public Result<?> handleRuntimeException(RuntimeException e) {
        return systemExceptionHandler.handle(e);
    }
}

四、异常处理实战案例（综合运用）

结合上述最佳实践和设计模式，我们以"用户管理系统"的异常处理为例，展示如何在实际项目中构建完整的异常处理体系。

4.1 案例架构

采用"Controller-Service-Dao"三层架构，异常处理体系分为三层：

Dao层：抛出底层异常（如SQLException），不处理；
Service层：使用"异常封装模式"，将底层异常封装为业务异常；
Controller层：使用"模板方法模式+全局异常处理器"，统一捕获所有异常，返回统一响应。

4.2 完整代码实现

java 复制代码

// 1. 自定义异常（业务异常）
public class BusinessException extends RuntimeException {
    private final String code;
    
    public BusinessException(String code, String message) {
        super(message);
        this.code = code;
    }
    
    public BusinessException(String code, String message, Throwable cause) {
        super(message, cause);
        this.code = code;
    }
    
    // getter
    public String getCode() { return code; }
}

// 2. 统一响应结果
public class Result<T> {
    private String code;
    private String message;
    private T data;
    
    // 静态方法：成功、失败
    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode("00000");
        result.setMessage("成功");
        result.setData(data);
        return result;
    }
    
    public static <T> Result<T> error(String code, String message) {
        Result<T> result = new Result<>();
        result.setCode(code);
        result.setMessage(message);
        return result;
    }
    
    // getter/setter
}

// 3. Dao层（抛出底层异常）
@Repository
public class UserDao {
    @Autowired
    private JdbcTemplate jdbcTemplate;
    
    public User selectById(String userId) throws SQLException {
        String sql = "select id, name, age from user where id = ?";
        try {
            return jdbcTemplate.queryForObject(sql, new Object[]{userId}, 
                    (rs, rowNum) -> new User(rs.getString("id"), rs.getString("name"), rs.getInt("age")));
        } catch (EmptyResultDataAccessException e) {
            // 转换为SQLException，便于Service层统一封装
            throw new SQLException("用户不存在，userId：" + userId, e);
        }
    }
}

// 4. Service层（异常封装）
@Service
public class UserService {
    @Autowired
    private UserDao userDao;
    
    public User getUserById(String userId) {
        // 参数校验（避免空指针，最佳实践2.7）
        if (userId == null || userId.trim().isEmpty()) {
            throw new BusinessException("10002", "userId不能为空");
        }
        
        try {
            return userDao.selectById(userId);
        } catch (SQLException e) {
            // 封装底层异常为业务异常，保留异常链（最佳实践2.6）
            throw new BusinessException("10001", "查询用户失败", e);
        }
    }
}

// 5. 全局异常处理（模板方法模式）
@RestControllerAdvice
public class GlobalExceptionHandler {
    // 处理业务异常
    @ExceptionHandler(BusinessException.class)
    public Result<?> handleBusinessException(BusinessException e) {
        log.error("业务异常：code={}, message={}", e.getCode(), e.getMessage(), e);
        return Result.error(e.getCode(), e.getMessage());
    }
    
    // 处理系统异常（非受检异常）
    @ExceptionHandler(RuntimeException.class)
    public Result<?> handleRuntimeException(RuntimeException e) {
        log.error("系统异常：{}", e.getMessage(), e);
        return Result.error("99999", "系统异常，请联系管理员");
    }
    
    // 处理其他未捕获的异常
    @ExceptionHandler(Exception.class)
    public Result<?> handleException(Exception e) {
        log.error("未知异常：{}", e.getMessage(), e);
        return Result.error("88888", "未知异常，请稍后重试");
    }
}

// 6. Controller层（调用Service，无需处理异常）
@RestController
@RequestMapping("/user")
public class UserController {
    @Autowired
    private UserService userService;
    
    @GetMapping("/{userId}&#34;)
    public Result<User> getUser(@PathVariable String userId) {
        User user = userService.getUserById(userId);
        return Result.success(user);
    }
}

4.3 案例说明

该案例综合运用了以下最佳实践和设计模式：

最佳实践：参数校验、精准捕获异常、异常封装、异常日志具体化；
设计模式：异常封装模式（Service层）、模板方法模式（全局异常处理）；
核心优势：异常处理与业务逻辑解耦，Controller层无需编写try-catch，代码简洁；异常信息清晰，便于排查；统一响应格式，提升前端对接效率。

五、常见异常处理误区总结

结合实际开发经验，我们整理了最容易踩坑的6个异常处理误区，再次强调规避方法：

误区1：捕获Exception父类 → 规避：精准捕获具体异常；
误区2：空catch块 → 规避：任何异常都需记录日志或处理；
误区3：手动关闭资源 → 规避：使用try-with-resources；
误区4：异常日志模糊 → 规避：包含场景、上下文、异常栈；
误区5：滥用受检异常 → 规避：按"可恢复性"区分受检与非受检异常；
误区6：用异常控制流程 → 规避：正常条件用if-else，异常仅处理意外。

六、总结

Java异常处理的核心是"优雅应对、精准定位、解耦复用"。本文从基础认知出发，详细讲解了异常处理的8条最佳实践，拆解了5种常用设计模式的落地方案，并通过实战案例展示了如何在项目中综合运用。

在实际开发中，异常处理没有"万能方案"，需结合项目架构、业务场景灵活选择：简单项目可直接遵循最佳实践，无需引入复杂设计模式；复杂项目可通过异常封装、策略模式、模板方法模式等，构建可扩展、可维护的异常处理体系。

最终目标是：让异常处理成为程序的"守护者"，而非"负担"，既保障程序的稳定性，又提升开发效率和可维护性。