定义检查型自定义异常需继承Exception，提供无参、String message及含上下文（如orderId）的构造方法，字段final并提供getter；运行时异常则继承RuntimeException，须包含message和cause构造方法；throw抛实例，throws声明类型；异常类应实现Serializable，避免不可序列化字段，统一message格式以利日志定位。
Java 中自定义异常不是必须继承 Exception，而是要看你想要的是检查型异常（checked）还是非检查型异常（unchecked）：继承 Exception（或其子类，但不包括 RuntimeException）就是 checked；继承 RuntimeException 就是 unchecked。
怎么定义一个典型的检查型自定义异常
适用于必须显式处理的业务场景，比如「用户余额不足」这类需要调用方强制 try-catch 或 throws 的情况。
- 继承
Exception，不要继承RuntimeException - 提供至少两个构造方法：无参、带
String message参数的 - 如果需要携带额外上下文（如错误码、订单 ID），可增加带参数的构造方法，并把字段设为
final且提供 getter - 不需要重写
toString()或printStackTrace()—— 父类已实现好
public class InsufficientBalanceException extends Exception {
private final String orderId;
public InsufficientBalanceException(String message) {
super(message);
this.orderId = null;
}
public InsufficientBalanceException(String message, String orderId) {
super(message);
this.orderId = orderId;
}
public String getOrderId() {
return orderId;
}
}
怎么定义一个运行时自定义异常
适用于编程错误或不可恢复的逻辑问题，比如「传入非法状态值」「配置项缺失」，调用方无需强制捕获。
- 直接继承
RuntimeException（不要绕道继承Exception再 throw new RuntimeException(...)） - 同样建议提供
String message和Throwable cause构造方法，方便链式异常追踪 - IDE 自动生成的构造方法基本够用，但要注意别漏掉 cause 版本 —— 否则嵌套异常信息会丢失
public class InvalidOrderStatusException extends RuntimeException {
public InvalidOrderStatusException(String message) {
super(message);
}
public InvalidOrderStatusException(String message, Throwable cause) {
super(message, cause);
}
}
throw 和 throws 容易混淆的点
很多人写完自定义异常类，却在使用时卡在语法上。关键就两条：
立即学习“Java免费学习笔记（深入）”；
-
throw是语句，用于「抛出一个异常实例」，后面跟的是对象：throw new InsufficientBalanceException("balance too low") -
throws是方法声明的一部分，用于「声明可能抛出的异常类型」，后面跟的是类名：public void pay() throws InsufficientBalanceException - 如果自定义异常是 unchecked（即继承
RuntimeException），throws声明可省略，但加上也合法 —— 不影响编译，只是没强制意义 - 检查型异常如果不声明
throws，又没在方法体内 try-catch，编译直接报错：unreported exception XXX; must be caught or declared to be thrown
序列化和日志打印时的坑
自定义异常如果要跨 JVM 传输（如 Dubbo、RMI）或写入日志文件，得小心几个细节：
- 务必让异常类实现
Serializable接口（JDK 8+ 默认支持，但显式写上更稳妥） - 避免在异常字段中存不可序列化的对象（如
Thread、Connection），否则反序列化失败 - 重写
getLocalizedMessage()没必要；但如果你覆盖了getMessage()，要确保它不依赖外部状态（比如不能去查数据库） - 日志框架（如 Logback）默认只打印
toString()，而它的默认实现是getClass().getName() + ": " + getMessage()—— 所以重点还是把message构造清楚
真正容易被忽略的是：很多团队写了自定义异常，却没统一 message 格式，导致日志里全是「余额不足」这种模糊描述，缺少订单号、用户 ID、时间戳等定位信息。与其靠 catch 后手动拼字符串，不如在构造方法里收口处理。
