throw负责“抛”，throws负责“传”；throw在方法体内创建并抛出异常对象，立即中断流程；throws在方法签名声明可能抛出的受检异常，供调用者知晓和处理。
throw 和 throws 到底谁负责“抛”，谁负责“传”？
简单说：throw 是“动手扔”，throws 是“提前声明我可能扔”。前者在方法体里执行，一抛就中断当前流程；后者写在方法签名上，是给调用者看的“风险预告”。没写 throws 却抛了受检异常（比如 IOException），编译直接报错；而 RuntimeException 子类（如 IllegalArgumentException）可以只用 throw，不声明也能过编译。
-
throw后必须跟一个异常对象，不能是类名（比如throw IllegalArgumentException是错的，得写throw new IllegalArgumentException(...)） -
throws后可跟多个异常类型，用逗号分隔，例如void read() throws IOException, SQLException - 子类重写父类方法时，
throws声明的异常不能比父类更宽——不能新增受检异常，也不能把父类的IOException换成更泛的Exception
异常怎么一层层往上“冒泡”？传播路径怎么看？
异常传播不是自动“找人处理”，而是沿着方法调用栈原路返回：从抛出点 → 直接调用者 → 上一层调用者……直到遇到第一个能匹配的 catch，或抵达 main 方法仍无人接手，JVM 就打印堆栈并终止线程。
- 只要某层方法没用
try-catch拦住异常，也**没在签名里用throws声明它**（对受检异常而言），编译就不通过 - 非受检异常（
RuntimeException及其子类）可以“静默传播”，但不等于该放任——比如NullPointerException本该靠空值校验预防，而不是等它一路冒泡到main - 在 IDE 里调试时，看控制台堆栈最上面几行（
Caused by:后面）通常就是原始抛出处，别被中间层层包装的代理类绕晕
为什么 catch 住之后再 throw，要小心“吃掉”原始堆栈？
直接 throw e; 不会丢堆栈，但写成 throw new RuntimeException("包装一下", e); 是安全的；而如果写成 throw new RuntimeException("包装一下");（没传原异常作 cause），原始异常的完整调用链就丢了——排查时只能看到新异常，找不到最初出问题的那行代码。
- 重抛异常时，优先用带
cause构造器的版本，尤其是封装业务异常时 - 不要为了“统一错误码”就捕获所有异常再转成同一个
MyAppException，除非你保留了原cause并在日志里完整输出 - log 框架打异常时，务必用
logger.error("msg", e)形式，而不是logger.error("msg" + e)——后者只打 toString()，没了堆栈
受检异常 vs 非受检异常：什么时候必须处理，什么时候可以不管？
关键不在“要不要处理”，而在“编译器逼不逼你处理”。受检异常（如 IOException）强制你面对潜在失败，这是 Java 的设计契约；非受检异常（如 IllegalArgumentException）代表编程错误，应靠逻辑校验提前拦截，而不是指望 catch 住再兜底。
立即学习“Java免费学习笔记（深入）”；
- 文件读取、数据库操作、网络请求这类外部依赖，几乎必然涉及受检异常，躲不开，老老实实
try-catch或向上throws - 参数校验失败、状态非法、业务规则冲突——这些该用非受检异常，且应在入口处（如 Controller 层）集中校验，避免让错误数据流入深层逻辑
- 自定义异常建议继承
RuntimeException，除非你明确需要编译器强制调用方处理（比如某个 SDK 要求用户必须应对某种配置缺失）
