14

InterruptedException在 Guava 中使用 Throwables.propagate(e) 时处理 s 的最佳做法是什么？

我喜欢使用throw Throwables.propagate(e)，尤其是在不引发检查异常以及异常处理是调用者责任的方法中。但它并没有达到我对 InterruptedException 的期望。

我不想失去线程被中断的事实，所以我最终写了如下内容：

public void run() {
    Callable c = ...;
    try {
        c.call();
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw Throwables.propagate(e);
    } catch (Exception e) {
        throw Throwables.propagate(e);
    }
}

有没有办法在番石榴中做到这一点？是否有（向后兼容？！）使用 Throwables.propagate() 之类的方法将线程设置为中断，如果它正在包装和传播 InterruptedException？

4

1 回答 1

8

方便的是，我们不久前在内部讨论了这个问题。我将复制并粘贴：

我的强硬观点Throwables.propagate(e)是，基本上throw new RuntimeException(e)人们不应该这样做，就像他们通常不应该写一样throw new RuntimeException(e)。（如果他们要写它，他们还不如直接写它，以便清楚发生了什么。）

我对——通常是人们如何让自己陷入这种混乱——的强硬观点catch (Exception e)是，他们通常也不应该那样做。（显然，在某些情况下catch (Exception e)显然是正确的做法（基本上是任何顶级的操作范围的 catch 块），但这些都是......显而易见的。）

我的强硬观点InterruptedException是，完全有InterruptedException实现Exception方式就是以这种方式破坏的：它需要特殊处理，而其他异常则不需要。

InterruptedException我对转换为 a的强硬意见RuntimeException是“不要”。（这就像我上面所说的许多其他东西一样，是有争议的。）

所以一方面，我不确定我们能做些什么来挽救propagate()。另一方面，也许让方法不那么糟糕是件好事。

再一次，考虑这个调用者，它捕获ExecutionException e：

throw Throwables.propagate(e.getCause());

中断消费者线程是错误的，就像e.getCause()直接抛出是错误的一样，因为中断是针对计算线程的，而不是针对消费者线程的。

我倾向于propagate()独自离开。（您可能猜到了，我个人倾向于弃用它，但这是一个更大的讨论。）

于 2012-10-10T16:58:12.633 回答