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

Question

我实现了 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:我们收到两个关于中断请求的通知:线程的中断状态和异常。最初，只有一个通知:线程的中断状态为真或抛出 InterruptedException，但不能同时抛出两者。

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

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

PPS(编辑)我不能让原始 InterruptedException 传播，因为 InputStream.read() 不能抛出 InterruptedException (它 throws IOException 并且确实不要扔任何东西)。而且我无法预测将调用 MyInputStream.read() 的上下文:MyInputStream 的实例可以传递给任何 Java 或第 3 方库函数，该函数需要InputStream 参数。

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

Answer 1

... should I reinterrupt the current thread before throwing a different exception?

如果栈上的东西要检查中断标志，那么是的。否则，没关系。

CONTRA: some functionality like logging may be not working before the interrupt status is cleared, which may cause subtle bugs.

通过阅读分析，您链接的错误仅适用于 Java 6 及更早版本，并且仅适用于 Solaris 平台。你现在可能可以打折了。 (除非你有一个财力雄厚的客户，否则你不应该为 Java 6 或更早版本做重要的应用程序。)

CONTRA: we get two notifications about the interrupt request: the thread's interrupted status and the exception.

它们是质量不同的通知类型......

PS It looks like whatever I do, the problem that InterruptedIOException is a very special kind of IOException requiring a special handler will not be solved.

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