runnable.run() 方法不能声明 throws 是因接口契约禁止扩展异常、线程调度机制无法承载受检异常传播、lambda 表达式受限于函数式接口定义，且设计目标是轻量解耦；需异常处理时应改用 callable 或在 run() 内捕获包装。

因为 Runnable 接口的 run() 方法签名被 Java 语言强制定义为 void run()，不带任何 throws 子句。这个限制不是疏漏，而是由接口契约和并发 API 设计原则决定的。

接口契约不允许扩展异常声明

Java 规定：实现类或 Lambda 表达式重写方法时，不能抛出比父接口方法声明更多、更宽泛的受检异常。由于 Runnable.run() 在接口中未声明 throws，所有实现都必须遵守这一约束——哪怕内部调用了可能抛出 IOException 或 SQLException 的代码，也不能在方法签名里加 throws。

线程调度机制无法承载受检异常传播

像 Thread.start()、ExecutorService.execute(Runnable) 这些启动入口，本身不声明抛出任何异常。如果允许 run() 抛出受检异常，调用链就不得不层层声明或捕获，破坏简洁性。例如：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• execute() 不会也不该强制调用方处理 IOException
• 无法让线程池统一向上透传异常，因为没有统一的异常出口
• Lambda 表达式依赖函数式接口定义，接口没写 throws，它就“没路可走”

设计目标是解耦与通用性

Runnable 的语义是“执行一个动作”，不承诺结果，也不负责异常传递。JDK 设计者刻意将其限定为轻量、无副作用的执行单元，便于组合、复用和嵌套。把异常处理责任留给实现者，在方法体内自行捕获、记录、降级或包装为 RuntimeException，反而更符合“职责内聚”的思路。

替代方案更匹配实际需求

如果你的任务天然需要暴露受检异常或返回结果，说明它已超出 Runnable 的能力边界。这时应直接选用：

• Callable<t></t>：其 call() 方法支持 throws Exception，配合 Future.get() 可完整获取原始异常
• 在 run() 内部用 try-catch 处理并记录日志，或用 new RuntimeException("描述", e) 包装后抛出（保留 cause）
• 设置 UncaughtExceptionHandler 作为兜底，捕获未处理的运行时异常

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南