需继承Exception或RuntimeException，因所有异常必须是Throwable子类，且编译器强制要求；前者用于必须处理的检查型异常（如IO失败），后者用于无需强制处理的非检查型异常（如业务校验失败）。
为什么需要继承 Exception 或 RuntimeException
Java 中所有异常都必须是 Throwable 的子类，而实际开发中你几乎只会继承 Exception（检查型异常）或 RuntimeException（非检查型异常）。不继承它们，编译器会直接报错：unreported exception XXX; must be caught or declared to be thrown。
选择哪个父类取决于是否强制调用方处理：比如业务校验失败（如用户名为空），通常用 RuntimeException 子类，避免到处写 try-catch；而像文件读取失败这种外部依赖问题，更适合 Exception 子类。
最简自定义异常类怎么写
一个能用的最小实现只需要两行：一个空构造函数 + 一个带 String 参数的构造函数。Java 异常机制依赖这两个构造器把消息传给父类。
public class UserNotFoundException extends RuntimeException {
public UserNotFoundException() {
super();
}
public UserNotFoundException(String message) {
super(message);
}
}
注意：不需要重写 toString() 或手动拼接堆栈——父类已做好。也不建议加额外字段（如错误码），除非真有多个地方要读取它且逻辑统一。
throw 时常见错误和写法差异
手动 throw 一个自定义异常，和 throw NullPointerException 没本质区别，但容易踩几个坑：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 忘记 new：写成
throw UserNotFoundException;会编译失败，必须是throw new UserNotFoundException("xxx"); - 消息写死又冗余：比如在 service 层抛出
new UserNotFoundException("用户不存在")，但调用方其实更想知道是哪个 ID 导致的——应该写成new UserNotFoundException("user id: " + userId + " not found") - 混用父类类型：如果定义的是
Exception子类，但方法没声明throws，编译就过不去；而RuntimeException子类可以随时 throw，无约束
什么时候该加构造器传 Throwable cause
只有当你想保留原始异常上下文时才需要。比如 DAO 层捕获了 SQLException，又想包装成业务异常向上抛，就得用带 cause 的构造器：
catch (SQLException e) {
throw new DataAccessException("查询用户失败", e);
}
否则，原始异常的堆栈就丢了，排查时只能看到“查询用户失败”，看不到底层是连接超时还是 SQL 语法错。这个构造器不是必须的，但一旦涉及异常转译，漏掉它会让日志失去关键线索。
真正难的不是写这个类，而是判断该不该让异常逃出当前方法、该不该包装、该不该记录日志——这些没法靠继承搞定。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
