throw new Throwable() 要求方法声明 throws Throwable 才能编译通过，但这是反模式：它过于宽泛，会捕获不可恢复的 Error，掩盖具体异常语义，违反异常设计原则，应改用具体异常如 IOException 或自定义 checked 异常。
在 Java 中，throw new Throwable() 抛出的是 检查型异常（checked exception），因为 Throwable 是所有异常的根类，而它的直接子类 Exception（除 RuntimeException 及其子类外）都属于检查型异常。
但关键点在于：
✅ Throwable 本身是检查型异常（即编译器要求必须处理），
❌ 你不能在方法签名中写 throws Throwable 来满足编译要求——不是语法错误，而是不推荐、不实用、且通常违反设计原则。
方法签名必须显式声明 throws Throwable
如果真写了 throw new Throwable()，编译器会强制你声明：
public void riskyMethod() throws Throwable {
throw new Throwable("oops");
}这语法合法，能通过编译。但问题不在“能不能”，而在“该不该”。
为什么几乎从不写 throws Throwable
-
Throwable太宽泛，掩盖了具体异常语义（比如是 I/O 错误？空指针？逻辑错误？） - 调用方无法针对性
catch，只能catch (Throwable t)—— 这会捕获Error（如OutOfMemoryError），而Error不应被普通代码捕获或处理 - 违反异常分类设计：
Error表示 JVM 严重问题，本就不该由业务代码throws或catch - IDE 和静态分析工具（如 Sonar、Checkstyle）通常会警告这种写法
正确做法：抛出更具体的异常类型
| 场景 | 推荐抛出 | 说明 |
|---|---|---|
| 业务逻辑错误 |
throws IllegalArgumentException / BusinessException（自定义 checked 异常） |
明确意图，调用方可精确捕获 |
| I/O 失败 | throws IOException |
标准 checked 异常，符合 API 规范 |
| 编程错误（不应恢复） |
throw new NullPointerException()（无需 throws 声明） |
RuntimeException 及其子类是 unchecked，不强制声明 |
| 需要强制调用方处理的自定义异常 | throws MyCheckedException |
继承 Exception，不继承 RuntimeException
|
例如：
立即学习“Java免费学习笔记（深入）”；
// ✅ 好：明确、安全、可维护
public void readFile(String path) throws IOException {
throw new IOException("read failed");
}
// ⚠️ 不推荐：太泛，且包含不可恢复的 Error
public void badMethod() throws Throwable { // 编译通过，但危险
throw new Throwable("don't do this");
}特殊情况：throws Throwable 真的有用吗？
极少数场景下可能见到，比如：
- 泛型反射调用（
Method.invoke()可能抛出InvocationTargetException，其getCause()是Throwable） - 某些底层框架的回调接口（如
Callable<V>的call()方法声明throws Exception，但实际可能包装任意Throwable）
即便如此，也应尽量转为更具体的异常再抛出，或用 throws Exception（比 Throwable 稍好，至少排除 Error）。
总结
-
throw new Throwable()要求方法签名写throws Throwable才能编译通过 - 但这是反模式：它破坏异常分类、增加调用方负担、隐藏真实问题
- 应该抛出具体异常（
IOException、自定义 checked exception 等），或让逻辑错误走RuntimeException -
throws Throwable不是 bug，而是设计缺陷的信号
不复杂但容易忽略。
