Go How the main thread in Java captures exceptions thrown by child threads __java

So to see this problem. First clear the bounds of the thread code. In fact, the boundaries defined by the Run method of the Runnable interface can be considered as the boundaries of the thread code. The Run method prototype in the Runnable interface is as follows:
<<
public void run ();
>>
All of the specific threads implement this method, so it is clear that the thread code cannot throw any checked exceptions. Checked exceptions in all threads can only be digested by the thread itself.   :) This itself is also consistent with the thread design concept, the thread itself is considered a separate execution fragment, it should be responsible for itself, so it is normal to digest all the checked exceptions.
This answers the landlord's first question: checked abnormal must be within the thread internal digestion.

However, in the thread code it is possible to throw errors (error) and run-level exceptions (RuntimeException). We can ignore the error, because the usual error should be left to the VM, and RuntimeException is quite normal, if the operation of a certain condition to meet the cause of the thread must be interrupted, you can choose to use the throw run level exception to handle, as follows:
<<
public void Run () {
if (...) throw new RuntimeException ();
}
>>
When the thread code throws a run-level exception, the thread interrupts. :) This is clearly explained in Java:
<< @see Thread
All threads this are not daemon threads have died, either by returning E Run method or ' by throwing a exception that propagates beyond the ' Run method '.
>>
But what effect does it have on the main thread that is being invoke? The main thread is unaffected by this, does not handle the runtimeexception, and cannot catch the exception at all. will continue to execute its own code:)
So it comes to the conclusion that thread-method exceptions can only be handled by themselves.

On the last point, do not believe that you can do such a test:
<<
public class Testthreadexception extends Thread {
public void Run () {
throw new RuntimeException ();
}

public static void Main (string[] args) throws Interruptedexception {
try {
New Testthreadexception (). Start ();
catch (RuntimeException ex) {
See if we can get here. :)
}

Thread.Sleep (1000);
See if we can get here. :)
}
}
>>
The result, of course, is not to catch the exception.

Do not remember where to see the code that can be handled to the runtimeexception thrown in the thread:

public class Applicationloader extends Threadgroup
{
Private Applicationloader ()
{

Super ("Applicationloader");

}

public static void Main (string[] args)
{

Runnable appstarter = new Runnable ()
{

public void Run ()
{
Invoke your Application (I.e.mysystem.main (args)

throw new NullPointerException (); example, throw a runtime exception
}
};

New Thread (New Applicationloader (), Appstarter). Start ();
}

We overload this method from our parent
Threadgroup, which'll make sure that it
Gets called when it needs to be. This is
Where the magic occurs.
public void uncaughtexception (thread thread, Throwable exception)
{
Handle the error/exception.
Typical operations might be displaying a
Useful dialog, writing to an event log, etc.

Exception.printstacktrace ();//example, print stack trace
}
}


Well, Uncaughtexception seems to be the only way to handle uncaught exceptions thrown by threads. It seems that there are careful people ah. Indeed, there is a chance of processing through the Threadgroup uncaughtexception approach. When a thread throws a uncaughtexception, the JVM invokes this method of Threadgroup. The default processing is as follows:
<<
public void Uncaughtexception (Thread t, Throwable e) {
if (parent!= null) {
Parent.uncaughtexception (t, e);
Or else if (! e instanceof Threaddeath)) {
E.printstacktrace (System.err);
}
}
>>
Each thread has a Threadgroup object that can be obtained by means of the Thread.getthreadgroup () method, which provides the default uncaught exception handling method above.
This is not mentioned above, because I think under normal circumstances, this method is enough to deal with. Or the idea of thread design: "Threading problems should be addressed by the thread itself, rather than being delegated to the outside." "Typically, there is no external need to handle the thread's exception. There are, of course, exceptions. :)

These are some of the information I saw on the Internet, I do not have the means to do, had to design static variables, (of course, the premise of this method is to add Thread.Join () method in the main thread, so that the main thread to wait for the child to complete the next step, otherwise the main thread ran out, the line Cheng error, Why did can not capture it)

The program is also strange, unexpectedly require the child thread to throw an exception, to stop the main thread, there is no ready-made method, the final definition of static variables.