定义受检异常类必须继承exception且不继承runtimeexception，类名不含“runtime”，并提供string和string+throwable两个构造函数；编译器仅在方法声明throws且被调用时强制处理。
Java里怎么定义一个受检异常类
必须继承 Exception（不能是 RuntimeException），且类名不带“Runtime”字样。JVM 和编译器靠这个继承链识别是否为受检异常——只要顶层父类是 Exception 且不是 RuntimeException 的子类，就强制调用方处理。
常见错误是误继承 RuntimeException 或写成 public class MyException extends Exception {} 却忘了加构造函数，导致调用时无法传入消息或 cause。
- 必须提供至少一个带
String参数的构造函数（用于传递错误信息） - 推荐再加一个带
String和Throwable参数的构造函数（支持链式异常） - 不需要重写任何方法，也不需要加
@Override
public class InsufficientBalanceException extends Exception {
public InsufficientBalanceException(String message) {
super(message);
}
public InsufficientBalanceException(String message, Throwable cause) {
super(message, cause);
}
}
为什么 throw 新异常时编译器没报错
编译器只在「方法声明抛出该异常」且「调用该方法」时才检查。如果只是定义了异常类但没在方法签名里用 throws 声明，或者声明了却没真正 throw，编译器不会介入。
典型疏漏：写了异常类，也写了 throws InsufficientBalanceException，但方法体里漏了 throw；或者用了 throw new RuntimeException(...) 混淆了类型。
- 确保抛出的是你自定义的异常实例，不是它的父类或别名
- 方法签名中必须显式列出该异常类型（或其父类，但会削弱强制性）
- 调用方若不捕获、也不向上声明，编译直接失败，错误信息是：
unreported exception XXX; must be caught or declared to be thrown
受检异常和 try-catch/throws 的配合逻辑
Java 强制处理的不是“抛出动作”，而是“调用一个声明了受检异常的方法”。所以重点不在 throw，而在方法签名 + 调用链。
例如 withdraw(double amount) throws InsufficientBalanceException 被 A 方法调用，A 就必须要么用 try-catch 处理，要么在自己签名里加 throws InsufficientBalanceException 向上传递。
- 不能只 catch
Exception就完事——虽然语法通过，但掩盖了具体风险语义 - 如果上层选择
throws，最终总得有人 catch，否则到main方法也得声明或处理 - 不要在 catch 里吞掉异常又不 re-throw，否则强制处理机制形同虚设
容易被忽略的兼容性和设计细节
受检异常一旦加进 public API，修改成本很高：删除或替换它会导致所有调用方编译失败。所以定义前要想清楚这个风险是否真该由调用方同步决策。
另一个隐形坑是序列化——如果异常要跨 JVM 传输（如 RMI、某些 RPC 框架），需确保所有字段可序列化，且默认构造函数存在（虽然不常用，但部分框架会反射调用）。
- 避免在异常类里放非
final、非基本类型、不可序列化的字段 - 不要在构造函数里做耗时操作（如 IO、网络请求），异常实例化应轻量
- 如果未来想升级为非受检异常，只能新增类，旧类保留 deprecated，不能直接改继承关系
强制处理本身不是目的，关键是让调用方在编译期意识到“这里可能失败，且失败原因明确”，而不是靠文档或约定去提醒。这点一旦漏掉，后面补救的成本远高于一开始想清楚要不要用。
