为什么 InterruptedException 是受检异常？答案

【问题标题】：Why Is InterruptedException a Checked Exception?为什么 InterruptedException 是受检异常？
【发布时间】：2015-02-17 21:25:16
【问题描述】：

在使用 Java 中的线程时，处理 InterruptedException 似乎是我的一个特别棘手的问题。我很欣赏它在我的线程终止时抛出的事实，因此为我提供了清理的机会。我觉得奇怪的是它不是一个未经检查的异常。

这会产生以下问题： a) 如果我想在我的线程应用程序中使用现有框架，我必须强制将其转换为框架接口接受的异常。因此，框架通常会误解它，而不是按照应有的方式清理或传播它。

b) 除非对堆栈中的每个调用都严格声明了 InterruptedException（通常不是因为 a），否则很难干净地关闭。

如果 InterruptedException 没有被选中，它似乎更有可能被正确使用并导致线程和应用程序的干净关闭。为什么不呢？

【问题讨论】：

我可以想象，在实现多线程解决方案时，让这个异常被选中还是不被选中的决定归结为可见性。有点像“嘿，你真的应该注意这一点并把它做好。”事物。在编译时强制执行此操作会迫使实施者至少考虑被中断的问题。如果不加以检查，则会将此问题的可见性转移到地平线以下。
投票结束，因为除了指定的人，我们只能做出有根据的猜测。
(а) 是您的框架的问题，而不是 InterruptedException 本身的问题。 (b) RuntimeException 表示编程错误； InterruptedException 不是编程错误的结果。
InterruptedExceptions 处理起来特别复杂，当它们发生时你需要关心线程的中断标志，它只会发生在阻塞操作中。为此，实际进行检查是一个很好的理由。
@eckes：我不明白异常处理是否复杂与是否应该检查有什么关系。

标签： java multithreading shutdown

【解决方案1】：

中断应该是合作的。我认为设计人员希望避免出现这样一种情况，即您可以通过中断线程将其炸毁，而线程没有代码来处理这种可能性。其目的似乎是让 Runnable 代码明确决定如何处理中断。许多框架或语言代码似乎是关于决定应该由谁负责，并试图使正确的用法变得明显，以最大程度地减少用户被烧伤的严重程度。这是那些判断电话之一。

在检查 InterruptedException 时，最坏的情况是异常被捕获，但以一种不是非常有用的方式。（实际上，绝对最坏的情况是中断标志没有恢复，使线程中的任何后续代码都不知道中断发生了。）如果未选中 InterruptedException（或者如果您将其包装在 RuntimeException 中，如链接中的文章所示cmets），异常可能会未处理并继续终止线程，如果线程不在停止位置，这可能会非常糟糕。

玩具示例和简单代码可以更好地处理未检查的 InterruptedExceptions；没有人会为捕捉异常而烦恼，它会起作用。然而，在真正的代码做大量工作时，这可能被认为是有害的。

检查异常是为了确保开发人员知道可以抛出异常，以便开发人员可以避免在线程正在执行的工作中间抛出异常的情况，可能会部分地离开工作 -在糟糕的状态下完成。

【讨论】：

我同意中断应该是合作的。但是，如果该异常未被检查，则它提供了“尽力而为”的折衷方案。您可以尽最大努力合作，也可以忽略它，但无论哪种方式，您都将被关闭，而不是可能继续在不稳定的状态下运行。
@Andy：这会有好处。无论如何，我不喜欢检查异常。