Dans un programme Java multithread, tous les threads ne sont pas autorisés à lancer des exceptions vérifiées non interceptées, ce qui signifie que chaque thread doit gérer ses propres exceptions vérifiées. Ceci est limité par la déclaration de méthode java.lang.Runnable.run() (car il n'y a pas de partie d'exception de lancement sur cette déclaration de méthode). Cependant, le thread peut toujours lever une exception non vérifiée. Lorsqu'une telle exception est levée, le thread se terminera, le thread principal et les autres threads ne seront pas du tout affectés, et l'exception levée par un certain thread ne sera pas perçue. all (il dit également que cette exception ne peut pas être détectée du tout). Cette conception de la JVM provient du concept : "Les threads sont des fragments de code exécutés indépendamment. Les problèmes de thread doivent être résolus par le thread lui-même plutôt que délégués à l'extérieur." ou exceptions non vérifiées) doivent être interceptés et traités dans les limites du code du thread (dans la méthode run).
Mais si le thread n'essaie pas d'intercepter une exception non vérifiée par lui-même et que nous voulons intercepter et gérer cette exception en dehors des limites du code du thread (en dehors de la méthode run), Java nous fournit un moyen d'intercepter une exception lorsqu'une exception se produit. dans le thread. Le mécanisme de rappel pour gérer les exceptions en dehors des limites du code du thread est la méthode setUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh) fournie par l'objet Thread.
En définissant un UncaughtExceptionHandler pour un thread via cette méthode, vous pouvez vous assurer que lorsqu'une exception se produit dans le thread, l'exception peut être gérée en rappelant la méthode public void uncaughtException(Thread t, Throwable e) de l'interface UncaughtExceptionHandler. ou le but de ceci est qu'il peut être utilisé dans le thread. En dehors des limites du code (en dehors de la méthode run() de Thread), il existe un endroit pour gérer les exceptions non interceptées. Mais ce qui devrait être particulièrement clair, c'est que même si l'exception est gérée dans la méthode de rappel, la méthode de rappel est toujours dans le thread qui a levé l'exception lors de son exécution !
Par rapport à la méthode ci-dessus, il existe une autre méthode de programmation qui peut être utilisée à titre de référence. Autrement dit, parfois l'appelant du thread principal peut simplement vouloir savoir quelles exceptions se sont produites lors de l'exécution du sous-thread, mais ce n'est pas nécessairement le cas. gérez-les ou traitez-les immédiatement.Ensuite, la méthode de lancement d'un thread enfant peut collecter les instances d'exception levées par le thread enfant et les renvoyer à l'appelant sous forme de liste d'exceptions, et l'appelant peut décider comment répondre en fonction de la situation anormale. . Cependant, il est important de noter que le thread enfant est déjà terminé à ce moment-là.