這么來看待這個問題。首先明確線程代碼的邊界。其實很簡單，Runnable接口的run方法所界定的邊界就可以看作是線程代碼的邊界。Runnable接口中run方法原型如下：
<<
public void run();
>>
而所有的具體線程都實現(xiàn)這個方法，所以這里就明確了一點，線程代碼不能拋出任何checked異常。所有的線程中的checked異常都只能被線程本身消化掉。:) 這樣本身也是符合線程的設計理念的，線程本身就是被看作獨立的執(zhí)行片斷，它應該對自己負責，所以由它來消化所有的checked異常是很正常的。
這樣就回答了樓主的第一個問題：checked異常一定要在線程內部消化。
但是，線程代碼中是可以拋出錯誤(Error)和運行級別異常(RuntimeException)的。Error俺們可以忽略，因為通常Error是應該留給vm的，而RuntimeException確是比較正常的，如果在運行過程中滿足了某種條件導致線程必須中斷，可以選擇使用拋出運行級別異常來處理，如下：
<<
public void run() {
if (...) throw new RuntimeException();
}
>>
當線程代碼拋出運行級別異常之后，線程會中斷。:)這點java中解釋得很清楚：
<< @see Thread
All threads that are not daemon threads have died, either by returning from the call to the run method or "by throwing an exception that propagates beyond the run method".
>>
但是對于invoke此線程的主線程會產生什么影響呢？主線程不受這個影響，不會處理這個RuntimeException，而且根本不能catch到這個異常。會繼續(xù)執(zhí)行自己的代碼 :)
所以得到結論：線程方法的異常只能自己來處理。
關于最后一點，不相信的話大家可以做這么一個試驗：
<<
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) {
// 看看能不能到達這里？ :)
}
Thread.sleep(1000);
// 看看能不能到達這里？ :)
}
}
>>
結果當然是捕捉不到異常了。
記不得在哪里看到的代碼，可以處理到線程中拋出的RuntimeException：
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 will 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
}
}
呵呵，uncaughtException好像是唯一能夠處理線程拋出的uncaught異常的入口?？磥磉€是有細心人啊。確實如此，通過ThreadGroup的uncaughtException方法還是有處理的機會。當線程拋出uncaughtException的時候，JVM會調用ThreadGroup的此方法。默認的處理如下：
<<
public void uncaughtException(Thread t, Throwable e) {
if (parent != null) {
parent.uncaughtException(t, e);
} else if (!(e instanceof ThreadDeath)) {
e.printStackTrace(System.err);
}
}
>>
每個Thread都會有一個ThreadGroup對象，可以通過Thread.getThreadGroup()方法得到，提供了上述默認的uncaught異常處理方法。
上面沒有提這點，因為俺認為在正常的情況下，這個方法的處理情況就已經足夠了。還是那個線程設計的理念：“線程的問題應該線程自己本身來解決，而不要委托到外部。”通常情況下，外部不需要處理線程的異常。當然也有例外。:)
以上是我在網(wǎng)上看到的一些資料，自己在做的時候沒辦法，只好設計靜態(tài)變量了，（當然，用這種方法的前提是在主線程中加入thread.join()方法，那樣主線程要等待子線程完成后再執(zhí)行下一步，不然主線程都跑完了，子線程才出錯，咋個都捕捉不到了）
程序也怪得很，竟然要求子線程拋異常后，要停掉主線程，也是沒有現(xiàn)成的方法，最后自己定義的靜態(tài)變量。
