Лучший способ обработки InterruptedException

Question

Я использую Thread.sleep (10000); поэтому мне нужно обработать InterruptedException. Я могу вызвать Thread.currentThread.interrupt(), а затем выбросить исключение в вызывающий класс, или я могу напрямую передать его классу вызовов или есть ли лучший способ его обработать?

Answer 1

Если у вас есть выделенный поток, который зацикливание и опроса, который звучит для меня как что-то, что нужно прекратить, когда программа закончится; если это не поток демона (подразумевая, что вы довольны тем, что он уходит без возможности очистки или закрытия ресурсов), он должен иметь возможность обрабатывать прерывания. Использование WatchService кажется хорошей идеей, но код, который использует WatchService, все еще должен знать, как обращаться с прерыванием.

Если вы пишете Runnable или Callable, который спит, вы можете использовать InterruptedException для выхода из цикла, который вы делаете, или вы можете поймать исключение и восстановить флаг прерывания, чтобы следующая проверка флага прерывания (с помощью Thread.currentThread().isInterrupted()) можно видеть, что поток был прерван:

while(!Thread.currentThread().isInterrupted()){ 
    //do something 
    try{ 
    Thread.sleep(5000);  
    } catch(InterruptedException e){ 
     Thread.currentThread().interrupt(); 
    } 
} 

в качестве альтернативы вы можете использовать InterruptedException, чтобы выйти из цикла:

try { 
    while (!Thread.currentThread().isInterrupted()) { 
     // do something 
     Thread.sleep(5000); 
    } 
} catch (InterruptedException e) { 
    // flag value is not used here 
    Thread.currentThread().interrupt(); 
} 

Если вы разрабатываете объект, который вы ожидаете гнездится внутри других объектов, затем выкиньте исключение и добавьте его в подпись метода. В качестве примера рассмотрим API doc для классов в пакетах java.util.concurrent, например BlockingQueue, см., Как методы, например put и предлагают throw InterruptedException. Когда объекты, созданные для параллелизма, складываются вместе, они должны взаимодействовать (и следить за тем, чтобы они не теряли следы прерванного состояния), чтобы удостовериться, что они могут очистить и прекратить реагирование.

Answer 2

В большинстве нормальных кодов вы не должны использовать sleep. Часто есть лучший способ сделать то, что вы хотите.

Я могу назвать Thread.currentThread.interrupt()

Это полезно, если вы хотите продолжать, как обычно, но без ожидания.

, а затем бросить исключение называть класс

ИЛИ Я бы бросить исключение, вы можете обернуть исключение с одним из вашего выбора.

или я могу сразу бросить его называть класс

Вы могли бы также не поймать в этом случае.

или есть ли лучший способ справиться с этим?

Это зависит от того, почему вы ожидаете прерывания потока. если я не ожидаю прерывания, я обертываю его AssertionError

Answer 3

Как правило, реконструируйте, если можете, или установите флаг прерывания, если вы не можете сбросить.

Хорошая статья на это http://www.ibm.com/developerworks/library/j-jtp05236/

, из которого это является наиболее значимой выдержкой будет:

Когда метод блокирования обнаруживает прерывание и бросает InterruptedException, он очищает статус прерывания. Если вы поймаете InterruptedException, но не можете его восстановить, вы должны сохранить доказательства , что произошло прерывание, чтобы код выше в стеке вызовов мог узнать о прерывании и ответить на него, если он хочет .

Answer 4

Я использую Thread.sleep (10000); поэтому мне нужно обработать InterruptedException.

Не обязательно. Есть разумные способы обработки InterruptedException, и есть глупые способы. Если ваша нить никогда не будет be прервана, то действительно ли имеет значение, каким образом вы выбираете?

Конечно, если вы считаете, что ваш код может когда-либо использоваться повторно, или если вы думаете, что другие программисты его прочтут, то вы можете пойти с умным способом.Если вы хотите попрактиковаться в хороших привычках кодирования, вы можете пойти со смарт-способом (множество примеров там, просто ожидая поиска с поиском в Google).

Но иногда мы просто хотим, чтобы написать быстрый хак, что мы будем использовать один раз, а затем выбросить ...