这么来看待这个问题。首先明确线程代码的边界。其实很简单，Runnable接口的run方法所界定的边界就可以看作是线程代码的边界。Runnable接口中run方法原型如下：  
  <<  
          public   void   run();  
  >>  
  而所有的具体线程都实现这个方法，所以这里就明确了一点，线程代码不能抛出任何checked异常。所有的线程中的checked异常都只能被线程本身消化掉。:)   这样本身也是符合线程的设计理念的，线程本身就是被看作独立的执行片断，它应该对自己负责，所以由它来消化所有的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到这个异常。会继续执行自己的代码   :)  
  所以得到结论：线程方法的异常只能自己来处理。  
   
  关于最后一点，不相信的话大家可以做这么一个试验：  
  <<  
  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异常处理方法。  
  上面没有提这点，因为俺认为在正常的情况下，这个方法的处理情况就已经足够了。还是那个线程设计的理念：“线程的问题应该线程自己本身来解决，而不要委托到外部。”通常情况下，外部不需要处理线程的异常。当然也有例外。:)  

以上是我在网上看到的一些资料，自己在做的时候没办法，只好设计静态变量了，（当然，用这种方法的前提是在主线程中加入thread.join()方法，那样主线程要等待子线程完成后再执行下一步，不然主线程都跑完了，子线程才出错，咋个都捕捉不到了）

程序也怪得很，竟然要求子线程抛异常后，要停掉主线程，也是没有现成的方法，最后自己定义的静态变量。