Я реализую MyInputStream.read()
и замечаю, что в этой функции может произойти InterruptedException
. После некоторого поиска я обнаружил, что обычно ловить InterruptedException
и повторно бросать InterruptedIOException
, что-то вроде:
try {
...
} catch (InterruptedException e) {
//Thread.currentThread().interrupt(); // <=== ???
throw new InterruptedIOException();
}
но только около 50% образцов кода Thread.currentThread().interrupt()
.
Ну, согласен, что самое худшее, что вы можете сделать с InterruptedException
, усвоить его, но следует перепроверить текущий поток до бросая другое исключение?
PRO: один запрос прерывания может иметь несколько "получателей".
CONTRA: некоторая функциональность как ведение журнала может не работать до того, как состояние прерывания будет очищено, что может вызвать тонкие ошибки.
CONTRA: мы получаем два уведомления о запросе прерывания: состояние прерывания потока и исключение. Изначально существует только одно уведомление: либо прерванный статус потока является истинным, либо генерируется InterruptedException
, но не оба.
PRO: никто не проверяет код в отношении исключений i/o, которые могут быть выбраны, а InterruptedIOException
отличается от других исключений i/o; a catch(IOException)
может усвоить прерванный статус.
PS Похоже на то, что я делаю, проблема, что InterruptedIOException
является особым видом IOException
, требующим специального обработчика, не будет решена.
PPS (EDIT)
Я не могу позволить оригиналу InterruptedException
распространяться, потому что InputStream.read()
не может выбрасывать InterruptedException
(it throws IOException
и ничего не бросать).
И я не могу предсказать контекст, в котором будет вызываться MyInputStream.read()
: экземпляр MyInputStream
может быть передан любой библиотечной функции Java или сторонней библиотеки, которая принимает аргумент InputStream
.
Что касается старой ошибки, похоже, что она была просто закрыта, а не исправлена; и сама идея прерванного состояния заключается в том, что код будет вести себя по-другому.