try catch 你真的会用了吗？

实质内容：try catch finally 只要你对错误try一次便会增加一倍错误处理时间。
我的问题：我们到底怎么处理错误。
我的方案：catch你所预料的错。
我的案例：
            小弟不才，维护2年前我们开发的项目。遇到让人发疯的问题。症状:“对不起，系统忙暂时不能提供服务，请与管理员联系。”这样的信息出现在我的系统出错的每一个角落，让我头都大了。我们开发使用的VS2005的web网站不是web项目。每一个页面产生一个dll文件，并且是乱七八糟的名字无法识别是那个页面对应的文件，于是乎我就疼苦了，主要一个页面的aspx.cs文件一修改那是全站发布，虽然说再发布不是问题，关键是小弟当年初出茅庐，不知天高地厚，把网站做出来的时候，才发现部署是一个大问题，说来惭愧被一知半解所害呀。当年也没有控制好技术风险呀，结果我是大量使用json，并且json数据也是生成静态的js文件，并且小弟当年将网站的图片切的很小，那是想呀能小就小，文件小速度快，素不知浏览器同时只能开启两个线程。小弟是自己找了个坑往里面跳呀，最惨的是小弟跳的是粪坑呀。
         小弟当年也没有使用log4net更谈不是对错误的及时报告了，当年我们团队使用的基本方式是：try catch(Exception ex) finally。这样基本上是全盘错误报不出来。维护的人想找到那出错，找不到了。怎么办了？小弟只有一个办法把try catch 注释掉。把系统往上一放在相同的条件下让他再错一次吧。小弟这样疼苦着，一次又一次。
       小弟后来长了记性，用这个方法来开发了一个winform项目，没有问题，出现错误了，但是出现的方式却是这样的。


      CTO跑来了，你们弄得东西错误报的太不美观了。“你们一个地方都没有try catch一下？”，这一下给慌乱，怎么办了？老办法try catch 怎么弄了不是web有一个applicationError吗？那我就只有找winform有没有全局的Exception结果有，便使用了Application.ThreadException事件。但是不巧的是多线程的异常处理不支持。得报这样的错误：
     小弟，四处求医以无终而还。
解决方案：
      小弟后自知这个异常处理不是一个小问题呀，便四处寻医异常处理，在参阅多家学说之后得一结论：捕获你所知道的异常，放出你不知道的异常。
题后小议：
      这话说来大家都知道，其实我在这罗嗦这话的道理。其实我使用异常来作为业务逻辑并没有错，错在我并没有使用正确这个业务逻辑。
try catch finally 我见到的常见写法有如下：
    try{
            ........
         }
      catch{
            
            }

            这种写法无非是把所有的异常都隐藏了。
         try
            {
            ......
            }
      catch(Exception ex)
      {

      }
      和以上的写法在执行结果上没有区别。
      try
      {
            ...
      }
      catch(Exception ex)
      {
            throw ex;
      }
      这种方法和不使用try catch我觉得没有区别，严格的说不是没有区别，区别就在于他try catch throw一次还让时间多出来一倍，在错误上显示也不是很明细（尤其是在堆栈跟踪方面），对于我们找错可能也不是很方便。如下图
      

            这样对于我们的异常处理可能不是很方便吧，无论是在开发还是在维护可能都是一个问题呀。
            而对于我来说比较喜欢采用的方式是如下：
            try
            {
                  ...
            }
            catch(System.DivideByZeroException ex)
             {
                        //如果内部可以预料的错误，并友好的向客户发送错误信息，并指明修改意见，再向日志系统发送错误信息。
                        //不在我预料范围内，那就不捕获。
                    log4net.error(ex);    //日志记录信息。
              }
            finally
            {
                 // 对一些资源释放。      
            }
            其实在这点上，微软的做法做的很漂亮，比如如果你的错误出现很明晰的错误地点以及错误原因，如果遇到com级别错误的时候他不会给你隐藏，还是给你说看。比较赞同这样的处理方式。维护的人不至于找不到错在哪里，并且当错误出现的时候不至于没个调用的地方都翻倍的耗时间。
声明：
    欢迎各位大侠指正哈。