必须继承Exception或RuntimeException，因JVM仅识别Throwable子类异常；继承Exception强制调用方处理，适合业务可控错误；继承RuntimeException则无需声明，适用于程序逻辑错误。
为什么必须继承 Exception 或 RuntimeException
Java 的异常体系强制要求自定义异常类必须是 Throwable 的子类，而实际开发中几乎总是选择继承 Exception（受检异常）或 RuntimeException（非受检异常）。不这样做会导致编译失败——比如直接继承 Object 写个 MyException，连 throw new MyException() 都过不了编译。
关键区别在于：继承 Exception 会让调用方**必须处理**（try/catch 或 throws），适合业务中明确需要强制干预的错误（如支付金额超限、用户未实名）；继承 RuntimeException 则无需强制声明，适合程序逻辑错误或不可恢复的意外（如参数为 null 且不该发生）。
- 不要试图绕过继承机制，用包装或代理方式模拟异常行为——JVM 不认，
catch不会捕获 - 如果想让异常既可检查又可运行时切换，得靠两个独立类，不能靠“动态继承”
- IDE 自动生成的构造函数常漏掉
cause参数，导致嵌套异常信息丢失
super(message) 和 super(message, cause) 怎么选
绝大多数自定义异常类至少要提供带 String 参数的构造方法，否则 new MyBusinessException("余额不足") 会报错。但仅此不够——当你的异常是由另一个异常触发的（比如数据库操作失败引发业务异常），必须把原始异常作为 cause 传进去，否则堆栈里看不到底层根因。
推荐构造函数组合：
-
public MyException(String message)→ 调用super(message) -
public MyException(String message, Throwable cause)→ 调用super(message, cause) - 可选：
public MyException(Throwable cause)→ 调用super(cause)，方便包装已有异常
public class InsufficientBalanceException extends Exception {
public InsufficientBalanceException(String message) {
super(message);
}
public InsufficientBalanceException(String message, Throwable cause) {
super(message, cause);
}
}
要不要重写 getMessage() 或 toString()
一般不用。父类 Exception 已经实现了清晰的 getMessage()（返回构造时传入的 message）和 toString()（含类名 + message）。除非你有强定制需求，比如所有业务异常必须前置固定前缀，才考虑重写：
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。
public class OrderException extends Exception {
public OrderException(String message) {
super("[订单系统] " + message);
}
// 不建议重写 getMessage() 去拼接，容易和 cause.getMessage() 混淆
}
更安全的做法是：在日志打印时统一加前缀，而不是污染异常对象本身。重写 toString() 尤其危险——很多监控系统、序列化工具依赖它的默认格式，改了可能导致告警解析失败。
- 日志框架（如 Logback）可通过
%X{traceId}等 MDC 字段补充上下文，比改异常更灵活 - 如果真要丰富异常信息，优先用额外字段 + getter（如
getOrderId()），而不是覆盖核心方法
序列化问题：serialVersionUID 必须显式声明吗
必须。自定义异常类默认实现 Serializable，一旦涉及远程调用（Dubbo、RMI）、缓存（Redis 存异常对象）、或集群间传递，没有显式 serialVersionUID 会导致 InvalidClassException：「local class incompatible」。
原因：JVM 自动生成的 UID 依赖类结构细节（方法签名、字段顺序等），微小改动就会变，而异常类常随业务迭代频繁修改字段（比如加个 errorCode int 字段）。
- 固定值推荐用
1L或时间戳（如20240501L），避免用 IDE 自动生成的长随机数 - 如果异常类确定永不序列化（如纯内存校验异常），可加
private static final long serialVersionUID = 0L;并注释说明 - 子类必须声明自己的
serialVersionUID，不会继承父类的
public class PaymentRejectedException extends RuntimeException {
private static final long serialVersionUID = 20240501L;
private final String transactionId;
public PaymentRejectedException(String message, String transactionId) {
super(message);
this.transactionId = transactionId;
}
public String getTransactionId() {
return transactionId;
}
}
实际项目中最容易被忽略的是 cause 的透传和 serialVersionUID 的维护——前者让问题排查断链，后者让上线后出现莫名其妙的反序列化失败。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
