private void BeginWaitingConnection()
        {
            try
            {
                Convert.ToInt32("abc");                
                this.thWaitingConnect = new Thread(new ThreadStart(WaitingConnection));
                this.thWaitingConnect.IsBackground = true;
                this.thWaitingConnect.Start();
            }
            catch (Exception ex)
            {
                Log.AddErr(ex);
                throw ex;
            }
        }         private void WaitingConnection()
        {
            try
            {
                Convert.ToInt32("abc");
            }
            catch (Exception ex)
            {
                Thread.CurrentThread.Abort();
                Thread.CurrentThread.Join();

                throw ex;
            }
        }
代码如上. 问题1:
蓝色字的Convert,也就是在线程外发生异常,catch之后可以正常往上抛.
但红色字的Convert,也就是在线程里发生异常,catch之后不能正常往上抛.
我的目的是写入日志,那在线程里发生异常,应该怎么处理呢? 难道就在线程里try catch,然后直接写日志吗? 
问题2:
线程内发生异常,是不是应该Abort,将他停掉呢?谢谢指教

解决方案 »

  1.   

    1.线程Abort本身就会引发异常,而且调用线程的Abort,一般是从外部线程调用,没见过自身这么调用的。
    2.即使线程不发生异常,catch后面没有代码,线程自然会终止。发生异常,也只是先执行catch之内的再执行catch之后的,没有的话自然终止,而且,使用throw再次抛出异常后,线程也会因为未处理异常终止。
    只要组织好try...catch...,完全可以使线程在发生不可恢复的异常之后,自然地终止,无须Abort,无须join。
      

  2.   

    当然,我也不主张在线程方法的catch中再次抛出异常。
      

  3.   


    那请问:我想写日志的话,是在线程里try catch,然后在catch里面写日志吗???
      

  4.   


    也不是窝如果我用线程调用 A(),  A()调用B(), B()调用C(), C()调用D(), 但是线程里是不能throw的.那我不是要在每个方法里try catch,然后再写日志? 这样代码显得比较累赘,有什么方法改善吗?
      

  5.   

    如果这些方法调用这么复杂的话,我建议你好好检查一下你的代码。也并不是说线程中不能throw,而是说,不应该throw到线程外部,因为这个很难处理的。可以象这样:
    private void threadProc()
    {
      ...
      try
      {
        ...
          try
          {
           ...
           }
          catch
           {
             ...
             throw
            }
             try
            {
             ...
             }
            catch
             {
               ...
               throw
              }
     ...
       catch
        {
           ...//可以在这里做日志
               //不要再throw就是了
         }
    }
      

  6.   

    总的一个思想,发生了不可恢复的异常之后,使它的执行流程迅速转移到线程的结束部分。
    最后的这个try...catch...一般来说,使用了某些资源的话,还应该加上finally块。
      

  7.   

    晕 那么多try catch
    如果这些方法调用这么复杂的话,我建议你好好检查一下你的代码。我的代码是:
    1.线程调用WaitingConnection(),用作等待客户端连接.
    2.当有客户端连上来的时候, 调用AnalyseCmd(), 用作分析命令(例如:登陆).
    3.分析到是哪种命令,再调用相应的处理方法请问,这存在什么问题吗?
      

  8.   

    你这里的 throw 主线程是捕获不到的,都挂了还 join 什么,可以不写, abort 也是多余的,join 的意思是调用方会等待一下这个线程,是阻塞的,所以加个时间比较好,不然一直僵在那里就玩了
      

  9.   

    这些方法还有别的地方会调用吗?没有的话,为什么要写成不同的方法?在我看来,你这个线程方法,和WaitingConnection(),AnalyseCmd()可以并成一个方法。
    你不要告诉我,这几个方法都是线程方法。
      

  10.   

    线程做个可控循环作为监听器,用委托或者事件实现回调,基本没什么问题,就是监听器的终止方法需要写一下。如果需要监听器挂了自动重启的话可以再实现一个 monitor 来检测
      

  11.   

    因为我认为 WaitingConnection(), AnalyseCmd() 是2个不同的概念,也可以说是不同的动作,在代码的设计上应该把他们分开,而不应合到一起. 而且AnalyseCmd()内容比较长,把他独立成一个方法,也好管理.