Si InterruptedException
se lanza un, significa que algo quiere interrumpir (generalmente terminar) ese hilo. Esto se activa mediante una llamada al interrupt()
método threads . El método de espera detecta eso y lanza unInterruptedException
para que el código de captura pueda manejar la solicitud de terminación de inmediato y no tenga que esperar hasta que finalice el tiempo especificado.
Si lo usa en una aplicación de un solo subproceso (y también en algunas aplicaciones de varios subprocesos), esa excepción nunca se activará. No recomendaría ignorarlo al tener una cláusula de captura vacía. El lanzamiento del InterruptedException
borra el estado interrumpido del hilo, por lo que si no se maneja correctamente, esa información se pierde. Por lo tanto, propondría ejecutar:
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
// code for stopping current task so thread stops
}
Lo que establece ese estado de nuevo. Después de eso, termina la ejecución. Este sería un comportamiento correcto, incluso si no se utiliza nunca.
Lo que podría ser mejor es agregar esto:
} catch (InterruptedException e) {
throw new RuntimeException("Unexpected interrupt", e);
}
... declaración al bloque de captura. Eso básicamente significa que nunca debe suceder. Entonces, si el código se reutiliza en un entorno en el que podría suceder, se quejará de ello.