Callable接口的call()方法声明throws Exception是Java语言契约设计，允许合法抛出受检异常；而Runnable的run()方法无throws子句，必须内部处理；ExecutorService中Callable异常被封装为ExecutionException，需通过future.get()捕获并用getCause()获取原始异常。
因为 callable 接口的 call() 方法签名中明确声明了 throws exception，这是由接口定义决定的，不是“绕过”规则，而是 java 语言层面对该接口的契约设计。
接口方法签名强制支持受检异常
Callable 是一个函数式接口，其核心方法定义为：
V call() throws Exception;这个 throws Exception 是方法声明的一部分，编译器会据此校验实现类：只要实现了 Callable，call() 方法就可以合法地向上抛出任意受检异常（如 IOException、SQLException 等），无需在方法体内 try-catch —— 这和 Runnable 的 run() 方法（void run()）形成根本区别。
Runnable 的 run() 方法为什么不能？
Runnable 自 Java 1.0 就存在，其 run() 方法定义为：
void run();它既没有返回值，也没有 throws 子句。这意味着：
- 任何受检异常都必须在 run() 内部捕获处理，否则编译失败；
- 若强行 throw new IOException()，编译器直接报错：unreported exception IOException; must be caught or declared to be thrown。
ExecutorService 提交后，异常去哪儿了？
你不会在控制台立刻看到 call() 抛出的异常，因为它被封装进 Future 的 get() 调用中：
- 任务执行中若抛出受检异常（比如 new Exception("timeout")），不会中断线程，也不会打印堆栈；
- 该异常会被捕获并包装为 ExecutionException，只有当你调用 future.get() 时才会抛出；
- 正确做法是 catch(ExecutionException e) 后，再通过 e.getCause() 获取原始异常。
这不是“特殊优待”，而是职责分离的设计
Callable 的 throws Exception 不是为了让开发者“省事”，而是为了匹配真实业务场景的需求：
- 数据库查询可能抛出 SQLException；
- HTTP 请求可能抛出 IOException；
- 解析配置可能抛出 ParseException。
这些异常本就需要上层决策——重试、降级、告警或透传。Callable 把异常传递权交还给调用方，而不是强制在线程内部吞掉或硬编码处理。
