java - 我应该在 `Thread.currentThread().interrupt()`之前先做 `throw new InterruptedIOException()`吗？

我实现了MyInputStream.read()，并注意到InterruptedException可能在此函数内发生。经过一些搜索后，我发现通常会捕获InterruptedException并重新抛出InterruptedIOException，例如:

    try {
        ...
    } catch (InterruptedException e) {
        //Thread.currentThread().interrupt(); // <=== ???
        throw new InterruptedIOException();
    }

但是只有大约50％的代码样本执行Thread.currentThread().interrupt()。
好吧，我们同意the worst thing you can do with InterruptedException is swallow it，但是我应该在抛出其他异常之前重新中断当前线程吗？

PRO:单个中断请求可能有多个“收件人”。

相反:在清除中断状态之前，某些功能like logging可能无法正常工作，这可能会导致一些细微的错误。

CONTRA:我们收到两个有关中断请求的通知:线程的中断状态和异常。最初，只有一个通知:线程的中断状态为true或抛出了InterruptedException，但不是两者都。

PRO:没有人真正针对可能引发的I/O异常测试代码，并且InterruptedIOException与其他I/O异常不同； catch(IOException)子句可能会吞下中断状态。

PS看来，无论我做什么，InterruptedIOException是一种非常特殊的IOException且需要特殊处理程序的问题都无法解决。

PPS(编辑)
我不能让原始的InterruptedException传播，因为InputStream.read()不能抛出InterruptedException(它是throws IOException，并且不抛出其他任何东西)。
而且我无法预测将在其中调用MyInputStream.read()的上下文:MyInputStream的实例可能会传递给任何带有InputStream参数的Java或第三方库函数。

对于the old bug，它似乎只是关闭而不是固定；而中断状态的想法是代码的行为会有所不同。

最佳答案

如果某个堆栈将要检查中断标志，则为是。否则，没关系。



根据我对分析的阅读，链接到的错误仅适用于Java 6及更早版本，并且仅适用于Solaris平台。您现在可以打折了。 (除非您的客户有很多钱，否则您不应该在Java 6或更早版本上进行大量的应用程序。)



从本质上说，它们是不同种类的通知...



实际上，更好的策略可能是在InterruptedIOException的捕获中设置中断标志...或简单地允许原始Interrupted异常传播。