lambda中infinite while循环中的thread.sleep不需要'catch(InterruptedException)'-为什么不需要呢？

Question

我的问题是关于InterruptedException，它是从Thread.Sleep方法抛出的。在使用executorservice时，我注意到一些我不理解的奇怪行为；我的意思是：

ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.submit(() -> {
        while(true)
        {
            //DO SOMETHING
            Thread.sleep(5000);
        }
    });

使用此代码，编译器不会给我任何错误或消息，即应该捕获来自Thread.Sleep的InterruptedException。但是当我试图改变循环条件并用下面这样的变量替换“true”时：

ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.submit(() -> {
        while(tasksObserving)
        {
            //DO SOMETHING
            Thread.sleep(5000);
        }
    });

编译器不断抱怨必须处理interruptedexception。有人能给我解释一下为什么会发生这种情况，为什么如果条件设置为true，编译器会忽略InterruptedException？

Answer 1

原因是这些调用实际上是对executorservice中可用的两个不同重载方法的调用；这些方法都采用不同类型的单个参数：

1. 未来 提交（可调用 任务）；
2. 未来<？>提交（可运行任务）；

然后，编译器将第一个问题中的lambda转换为可调用的<？>函数接口（调用第一个重载的方法）；在第二种情况下，将lambda转换为runnable函数接口（因此调用第二个重载方法），因此需要处理抛出的exception；但在前面使用callable的情况下则不是这样。

null

如果我们切换到将代码修剪成相关部分的示例（以便简单地研究奇怪的部分），那么我们可以编写与原始示例等价的代码：

    ExecutorService executor = Executors.newSingleThreadExecutor();

    // LAMBDA COMPILED INTO A 'Callable<?>'
    executor.submit(() -> {
        while (true)
            throw new Exception();
    });

    // LAMBDA COMPILED INTO A 'Runnable': EXCEPTIONS MUST BE HANDLED BY LAMBDA ITSELF!
    executor.submit(() -> {
        boolean value = true;
        while (value)
            throw new Exception();
    });

通过这些示例，可能更容易观察到第一个转换为可调用的<？>而第二个转换为可运行的的原因是编译器推断。

在这两种情况下，lambda主体都是void兼容的，因为块中的每个return语句都具有return；的形式。

现在，在第一种情况下，编译器执行以下操作：

1. 检测到lambda中的所有执行路径都声明抛出检查异常（从现在起，我们将引用“exception”，仅表示“checked exceptions”）。这包括调用声明抛出异常的任何方法，以及显式调用抛出新的 () 。
2. 正确地得出结论：lambda的整个主体相当于声明抛出异常的代码块；当然必须执行以下操作：处理或重新抛出。
3. 由于lambda不处理异常，因此编译器默认假定必须重新引发这些异常。
4. 安全地推断此lambda必须匹配不能正常完成的功能接口，因此是值兼容的。
5. 由于callable<？>和runnable是此lambda的潜在匹配项，编译器选择最特定的匹配项（以覆盖所有方案）；它是可调用的<？>，将lambda转换为它的实例，并创建对提交（可调用的<？>)重载方法的调用引用。

1. 检测lambda中可能存在未声明抛出异常的执行路径（取决于待求值逻辑）。
2. 由于不是所有的执行路径都声明抛出异常，编译器得出结论lambda的主体不一定等同于声明抛出异常的代码块--编译器并不关心/注意代码的某些部分是否声明它们可以，只有在整个主体是否声明时才会这样做。
3. 安全地推断lambda不是值兼容的；因为它可以正常完成。
4. 选择Runnable（因为它是lambda要转换的唯一可用的拟合函数接口），并创建对submit(Runnable)重载方法的调用引用。所有这一切的代价是将处理任何异常的责任委托给用户，不管这些异常发生在lambda主体的各个部分中。

这是一个很好的问题-我有很多乐趣追下去，谢谢！