Se um InterruptedException
for lançado, significa que algo deseja interromper (geralmente encerrar) esse segmento. Isso é disparado por uma chamada ao interrupt()
método threads . O método de espera detecta isso e lança umInterruptedException
para que o código catch possa lidar com a solicitação de encerramento imediatamente e não tenha que esperar até que o tempo especificado termine.
Se você usá-lo em um aplicativo single-threaded (e também em alguns aplicativos multithread), essa exceção nunca será disparada. Ignorá-lo por ter uma cláusula catch vazia, eu não recomendaria. O lançamento de InterruptedException
limpa o estado interrompido da discussão, então, se não for tratada corretamente, essas informações serão perdidas. Portanto, eu proporia executar:
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
// code for stopping current task so thread stops
}
O que define esse estado novamente. Depois disso, termine a execução. Este seria um comportamento correto, mesmo difícil nunca usado.
O que pode ser melhor é adicionar isto:
} catch (InterruptedException e) {
throw new RuntimeException("Unexpected interrupt", e);
}
... declaração para o bloco catch. Isso basicamente significa que isso nunca deve acontecer. Portanto, se o código for reutilizado em um ambiente onde isso possa acontecer, ele reclamará.