¿Cuándo Thread.sleep de Java lanza InterruptedException?

multithreading interrupted-exception

Question

¿Cuándo Thread.sleep de Java lanza InterruptedException? ¿Es seguro ignorarlo? No estoy haciendo multihilo. Solo quiero esperar unos segundos antes de volver a intentar alguna operación.

Answer 1

El boletín de Java Specialists (que puedo recomendar sin reservas) tenía un artículo interesante sobre esto y cómo manejar la InterruptedException . Vale la pena leer y digerir.

Answer 2

En general, NO debes ignorar la excepción. Eche un vistazo al siguiente artículo:

No tragues interrupciones

En ocasiones, lanzar InterruptedException no es una opción, como cuando una tarea definida por Runnable llama a un método interrumpible. En este caso, no puede volver a lanzar InterruptedException, pero tampoco desea hacer nada. Cuando un método de bloqueo detecta la interrupción y lanza InterruptedException, borra el estado interrumpido. Si detecta InterruptedException pero no puede volver a lanzarlo, debe conservar la evidencia de que la interrupción ocurrió para que el código más arriba en la pila de llamadas pueda enterarse de la interrupción y responder si así lo desea. Esta tarea se realiza llamando a interrupt () para "reinterrumpir" el hilo actual, como se muestra en el Listado 3. Como mínimo, siempre que detecte InterruptedException y no lo vuelva a generar, vuelva a interrumpir el hilo actual antes de volver.

public class TaskRunner implements Runnable {
    private BlockingQueue<Task> queue;

    public TaskRunner(BlockingQueue<Task> queue) { 
        this.queue = queue; 
    }

    public void run() { 
        try {
             while (true) {
                 Task task = queue.take(10, TimeUnit.SECONDS);
                 task.execute();
             }
         }
         catch (InterruptedException e) { 
             // Restore the interrupted status
             Thread.currentThread().interrupt();
         }
    }
}

• De No tragar interrupciones

Vea el documento completo aquí:

http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html?ca=drs-

Answer 3

La InterruptedException generalmente se lanza cuando se interrumpe el sueño.

Answer 4

Los métodos como sleep() y wait() de la clase Thread pueden lanzar una InterruptedException . Esto sucederá si otro thread quisiera interrumpir el thread que está esperando o durmiendo.

Answer 5

Si se lanza una excepción interrumpida, significa que algo quiere interrumpir (generalmente terminar) ese subproceso. Esto se desencadena mediante una llamada al método threads interrupt (). El método de espera detecta eso y arroja una excepción InterruptedException para que el código de captura pueda manejar la solicitud de terminación de inmediato y no tenga que esperar hasta que se agote el tiempo especificado.

Si lo usa en una aplicación de subproceso único (y también en algunas aplicaciones de subprocesos múltiples), esa excepción nunca se desencadenará. Ignorarlo al tener una cláusula de captura vacía no lo recomendaría. El lanzamiento de la InterruptedException borra el estado interrumpido del hilo, por lo que si no se maneja correctamente esa información se pierde. Por lo tanto, me gustaría proponer correr:

} catch (InterruptedException e) {
  Thread.currentThread().interrupt();
  // code for stopping current task so thread stops
}

Lo cual establece ese estado nuevamente. Después de eso, termina la ejecución. Este sería un comportamiento correcto, incluso resistente nunca utilizado.

Lo que podría ser mejor es agregar un:

} catch (InterruptedException e) {
  assert false;
}

declaración al bloque de captura. Eso básicamente significa que nunca debe suceder. Entonces, si el código se reutiliza en un entorno donde podría ocurrir, se quejará al respecto.

Answer 6

Una forma sólida y fácil de manejarlo en código de un solo subproceso sería atraparlo y retrotraerlo en una RuntimeException, para evitar la necesidad de declararlo para cada método.