runnable 的 run() 方法不支持 throws 子句，故无法直接抛出受检异常；应优先选用 callable + future 处理需返回结果或暴露受检异常的场景，或在 run() 内部捕获处理、降级、记录日志，必要时用带消息和 cause 的 runtimeexception 包装，辅以 uncaughtexceptionhandler 兜底。

runnable 的 run() 方法签名固定为 public void run()，不支持 throws 子句，因此无法直接抛出受检异常（如 ioexception、sqlexception）。这不是设计疏漏，而是接口契约决定的——它专注“执行动作”，不承担“异常传播”职责。要避免这种语法尴尬，关键不是强行绕过限制，而是选择更匹配语义的抽象方式。

优先改用 Callable + Future

如果你的任务本就需要返回结果、或必须暴露受检异常供调用方决策，Runnable 本身就不是最佳选择。换成 Callable 是最自然的解法：

• Callable.call() 允许声明 throws 任意异常，包括受检异常
• 通过 ExecutorService.submit() 提交后获得 Future，调用 get() 时可捕获 ExecutionException，再用 getCause() 取出原始异常
• 无需手动包装、无信息丢失，异常语义完整保留

在 run() 内部完成闭环处理

如果任务本身是“fire-and-forget”型（比如日志上报、状态刷新、缓存预热），异常属于可预期的运行时干扰，就该在 run() 内消化掉：

• 用 try-catch 捕获受检异常，记录带上下文的错误日志（如 SLF4J 的 logger.error("读取配置失败", e)）
• 根据业务逻辑执行降级：返回默认值、触发重试（限次）、切换备用数据源
• 避免空 catch 或仅 e.printStackTrace()，那等于掩盖问题

用 RuntimeException 包装（仅当必要时）

若你确实需要让异常“穿透”出来（例如测试断言、快速失败调试），可将受检异常转为运行时异常，但务必规范操作：

• 使用带消息和 cause 的构造器：throw new RuntimeException("加载证书失败", e)
• 不推荐裸写 throw new RuntimeException(e)，缺失描述性信息会加大排查难度
• 这不是替代方案，而是权宜之计——它把编译期检查转为运行期风险，适合内部工具类或脚手架代码

设置 UncaughtExceptionHandler 作兜底

对未捕获的运行时异常（包括上面包装抛出的），可为线程指定处理器，防止静默终止：

• 调用 thread.setUncaughtExceptionHandler((t, e) -> logger.error("线程 {} 异常终止", t.getName(), e))
• 或全局设置 Thread.setDefaultUncaughtExceptionHandler(...)
• 注意：它只捕获未处理的 RuntimeException 和 Error，对受检异常无效——后者必须在 run() 内处理