如何正确抛出和捕获自定义异常：避免常见反模式-java教程-PHP中文网

本文详解在 try-catch 中抛出自定义异常的规范做法，重点剖析直接捕获通用 exception、丢弃原始堆栈、忽略因果链等典型反模式，并提供可落地的重构方案与最佳实践。

本文详解在 try-catch 中抛出自定义异常的规范做法，重点剖析直接捕获通用 exception、丢弃原始堆栈、忽略因果链等典型反模式，并提供可落地的重构方案与最佳实践。

在 Java 异常处理中，看似简单的代码片段往往暗藏设计隐患。例如以下写法：

public void method() {
    try {
        throw new MyException("Error occurred");
    } catch (Exception e) {
        throw new MyException("Something went wrong");
    }
}

表面看是“捕获后重抛”，实则存在三重严重问题：逻辑冗余、因果链断裂、类型滥用。它并非异常转换，而是用 try-catch 故意绕过控制流——第一行抛出的异常必然被同一 catch 捕获，原始消息 "Error occurred" 永远不会暴露，堆栈跟踪也指向第二处 throw，彻底掩盖真实错误源头。

✅ 正确做法一：精准捕获 + 保留因果链

应明确区分“本意就是抛出该异常”与“因其他异常而兜底处理”。若需包装异常，必须传递原始 Throwable 作为 cause：

// ✅ 正确：保留原始异常上下文
try {
    riskyOperation();
} catch (MyException e) {
    throw e; // 直接重抛，不丢失堆栈
} catch (Exception e) {
    throw new MyException("Operation failed unexpectedly", e); // 关键：传入 e 作为 cause
}

为此，你的自定义异常类必须支持带 cause 的构造器：

public class MyException extends Exception {
    public MyException(String message) {
        super(message);
    }

    // 必须提供此构造器，否则无法建立因果链
    public MyException(String message, Throwable cause) {
        super(message, cause);
    }
}

⚠️ 若无法修改旧版异常类（如第三方库），可用 initCause() 补救：
MyException wrapped = new MyException("Fallback error");
wrapped.initCause(originalException); // 手动注入因果关系
throw wrapped;

✅ 正确做法二：消息设计遵循“类型语义 + 补充信息”原则

异常消息不是自由文本，而是结构化诊断数据。类型名定义问题范畴，消息仅补充唯一性上下文：

// ✅ 推荐：类型精准 + 消息精简（仅文件路径）
throw new NoSuchFileException("/data/config.json");

// ❌ 反模式：消息重复类型语义
throw new NoSuchFileException("File not found: /data/config.json"); // "not found" 冗余
throw new RuntimeException("Something went wrong"); // 类型模糊，消息无信息量
throw new IOException("Error! Failed to read!"); // 标点干扰，且未说明具体资源

理想的消息应满足：无标点结尾、不含类型同义词、仅含业务关键参数（如 ID、URL、配置项名）。

✅ 正确做法三：慎用 catch (Exception e) —— 仅限 Launch Point Runner

通用异常捕获（catch (Exception e)）仅在“启动点处理器”（Launch Point Runner）中合法，例如：

public static void main(String[] args) throws Exception
Web 框架中的 Controller 方法（由 Spring/Dropwizard 等统一拦截）
消息队列消费者入口方法

这些位置的职责是：统一记录日志、添加请求上下文（IP/TraceID）、返回用户友好错误页、触发告警。此时捕获 Exception 是合理的，因为所有未处理异常都应交由该层兜底。

而在业务逻辑层，catch (Exception e) 是危险信号。它会吞噬 InterruptedException、OutOfMemoryError 等本应立即终止的严重异常，或掩盖本可针对性恢复的特定异常（如 SQLException 可重试，IllegalArgumentException 应修正输入）。应改为：

// ✅ 按需捕获具体异常
try {
    saveToDatabase(data);
} catch (SQLTimeoutException e) {
    retryWithBackoff(); // 可恢复场景
} catch (SQLIntegrityConstraintViolationException e) {
    throw new BusinessException("Duplicate key: " + data.getId(), e);
} catch (SQLException e) {
    throw new DataAccessException("Failed to persist data", e); // 包装为领域异常
}