该抛Error时仅限JVM无法恢复的严重问题（如OutOfMemoryError），业务异常必须用Exception；checked异常强制调用方处理，unchecked由程序员自主决定捕获。
什么时候该抛 Error，而不是 Exception
Error 表示 JVM 无法恢复的严重问题，比如 OutOfMemoryError、StackOverflowError 或 NoClassDefFoundError。这类错误不是程序逻辑能处理的，也不该被 catch——即使写了 catch (Error e)，通常也只是记录日志后让进程退出。
常见误用：把自定义“系统不可用”类命名为 XXXError（如 DatabaseConnectionError），这违反语义。它本质是可预期、可重试、可降级的业务异常，应继承 Exception 或其子类。
- 你不能也不应该 try-catch
VirtualMachineError子类 - JVM 启动失败、类加载器崩溃、本地方法栈溢出——这些场景下程序已失去可控性
- 框架或 SDK 内部遇到致命故障时，才可能主动 throw
Error；业务代码中几乎从不 new 它
RuntimeException 和普通 Exception 怎么选
关键看是否强制调用方处理：Exception 及其子类（除 RuntimeException 外）是 **checked exception**，编译器强制你 try/catch 或 throws；而 RuntimeException 是 unchecked，由程序员自主决定是否捕获。
典型例子：NullPointerException 是 unchecked，因为它是编程疏漏，应在开发阶段修复；IOException 是 checked，因为文件读写、网络请求等外部依赖失败是常态，调用方必须明确策略（重试？返回默认值？转为用户提示？）。
立即学习“Java免费学习笔记（深入）”；
- 输入校验失败（如参数为 null）→ 抛
IllegalArgumentException（RuntimeException） - 数据库查询超时 → 抛
SQLException（checked），除非你封装成 DAO 层统一转为 unchecked - HTTP 调用返回 404 → 建议包装为业务相关的 unchecked 异常（如
UserNotFoundException），避免上层堆满 try-catch
自定义异常该继承哪个父类
不要一上来就继承 Exception 或 RuntimeException。先问自己两个问题：调用方是否必须处理它？这个异常是否代表一种稳定的契约？
如果答案是“是”，且该异常在多数使用场景下都需要显式应对（例如支付扣款失败需触发退款流程），那就用 checked exception；否则，优先用 unchecked，并确保类名以 Exception 结尾（别用 Error）。
public class InsufficientBalanceException extends RuntimeException {
public InsufficientBalanceException(String message) {
super(message);
}
}
- 避免继承
Error自定义异常——这是最常踩的命名陷阱 - checked 异常一旦加入 public API，后续删除或改为 unchecked 会破坏二进制兼容性
- Spring 等主流框架默认将未声明的异常（包括 unchecked）转为 500，但你可以用
@ExceptionHandler统一映射，所以实际开发中 unchecked 更灵活
throw 和 throws 的边界容易模糊
throw 是动作，发生在方法体内；throws 是声明，写在方法签名后，只对 checked exception 有意义。对 RuntimeException 写 throws 不报错，但属于冗余信息，多数 IDE 会警告。
一个具体坑：在 lambda 表达式里抛 checked exception 会编译失败，因为函数式接口方法签名没声明 throws。此时要么用 try-catch 包裹，要么借助包装工具类（如 ThrowingFunction），但更推荐重构为 unchecked。
- 接口方法声明了
throws IOException，实现类可以抛更具体的FileNotFoundException，但不能抛SQLException - private 方法内部 throw
Exception没问题，但 public 方法若 throw checked exception，等于把处理责任强加给所有调用方 - log.error("xxx", e) 后又
throw e，若 e 是 checked，必须在方法签名补throws；若已 catch 过，再 throw 新异常，注意保留原异常链：throw new ServiceException("xxx", e)
Error 和 Exception，而是忽略了“谁该负责处理它”这个契约问题。越底层的模块（如数据访问层）越倾向抛 checked，越上层（如 Web 控制器）越倾向用统一异常处理器转为 JSON 错误响应——中间那层业务服务，才是最该谨慎设计异常类型的地方。 
