A brief analysis of exception handling mechanism in Java Multi-threading _java

In a Java multithreaded program, all threads are not allowed to throw an checked exception, meaning that each thread needs to dispose of its own checked exception. This is constrained by the Java.lang.Runnable.run () method declaration (because there is no throw exception part of this method declaration). However, a thread can still throw unchecked exception, and when such an exception runs, the thread ends, and the main thread and other threads are completely unaffected and fully aware of the exception that is thrown by a thread (which is said to be completely unable to catch the exception). This design of the JVM stems from the idea that the thread is a piece of code that executes independently, and that the thread's problem should be resolved by the thread itself, rather than being delegated to the outside. "Based on this design concept, in Java, the thread method exception (whether checked or unchecked exception) should be within the thread code boundary (within the Run method) for a try catch and dispose of it.

But if the thread does not have its own try to catch a unchecked exception, and we want to catch and handle the exception outside the thread code boundary (outside the Run method), Java provides us with a callback mechanism that can handle exceptions outside of the thread code boundary when an exception occurs within threads, that is, the setuncaughtexceptionhandler provided by the thread object ( Thread.uncaughtexceptionhandler eh) method.

By using this method to set a uncaughtexceptionhandler for a thread, you can make sure that it is able to pass a callback uncaughtexceptionhandler the public void of the interface when there is an exception The uncaughtexception (thread T, Throwable e) method handles exceptions, such that the benefit or purpose is to be outside the thread code boundary (outside the thread's Run () method), and one place to handle the unhandled exception. However, it is particularly clear that although the exception is handled in the callback method, the callback method is still executing in the thread that throws the exception!

There is also a programmatic way to learn from the above methods, that is, sometimes the caller of the main thread may just want to know what happened during the execution of the child thread, and not necessarily handle it or deal with it immediately. Then the method of initiating a child thread can be collected as a exception list to be returned to the caller by the exception instance thrown by the thread, and the call callers decide how to respond according to the exception. However, it is particularly noteworthy that the child thread is already terminated at this time.