En un programa Java multiproceso, no todos los subprocesos pueden generar excepciones comprobadas no detectadas, lo que significa que cada subproceso debe manejar sus propias excepciones comprobadas. Esto está restringido por la declaración del método java.lang.Runnable.run() (porque no hay una parte de excepción de lanzamiento en esta declaración de método). Sin embargo, el subproceso aún puede generar una excepción no verificada. Cuando se lanza dicha excepción, el subproceso finalizará y el subproceso principal y otros subprocesos no se verán afectados en absoluto, y la excepción lanzada por un determinado subproceso no se percibirá. all (también dice que esta excepción no se puede detectar en absoluto). Este diseño de JVM se origina en el concepto: "Los subprocesos son fragmentos de código ejecutados de forma independiente. Los problemas de los subprocesos deben ser resueltos por el propio subproceso en lugar de delegarse al exterior". Según este concepto de diseño, en Java, los subprocesos son excepciones de método (si están marcadas). o excepciones no marcadas) se deben intentar capturar y manejar dentro de los límites del código del subproceso (dentro del método de ejecución).
Pero si el subproceso no intenta detectar una excepción no comprobada por sí solo y queremos detectar y manejar esta excepción fuera de los límites del código del subproceso (fuera del método de ejecución), Java nos proporciona una manera de detectar una excepción cuando ocurre una excepción. dentro del hilo El mecanismo de devolución de llamada para manejar excepciones fuera del límite del código del hilo es el método setUncaughtExceptionHandler (Thread.UncaughtExceptionHandler eh) proporcionado por el objeto Thread.
Al configurar un UncaughtExceptionHandler para un subproceso a través de este método, puede asegurarse de que cuando se produzca una excepción en el subproceso, la excepción pueda manejarse volviendo a llamar al método public void uncaughtException (Thread t, Throwable e) de la interfaz UncaughtExceptionHandler. El propósito de esto es que se puede usar en el hilo. Fuera de los límites del código (fuera del método run() de Thread), hay un lugar para manejar excepciones no detectadas. Pero lo que debería quedar particularmente claro es que aunque la excepción se maneja en el método de devolución de llamada, ¡el método de devolución de llamada todavía está en el hilo que lanzó la excepción cuando se ejecuta!
En comparación con el método anterior, existe otro método de programación que se puede utilizar como referencia. Es decir, a veces la persona que llama al hilo principal puede simplemente querer saber qué excepciones se han producido durante la ejecución del subproceso, pero no necesariamente. manejarlos o manejarlos inmediatamente. Luego, el método de iniciar un subproceso secundario puede recopilar las instancias de excepción lanzadas por el subproceso secundario y devolverlas a la persona que llama como una Lista de excepciones, y la persona que llama puede decidir cómo responder de acuerdo con la situación anormal. . Sin embargo, es importante tener en cuenta que el subproceso secundario ya finalizó en este momento.