关于异常处理的一点看法

      很多人在很多情况下直接将代码try  catch就好了,但是这个给调试以及以后的可维护性带来非常麻烦了。我的观点则认为：如果程序运行在某个阶段，出现必须的异常，直接异常，交给最外层的逻辑或者交给表现层的异常处理来处理。这里当然包括进入的参数必须检查，而事实上我很少看见有人这么做。

 

　　这里我们先谈论为什么不要把这个异常在知道可能发生的异常杀掉呢？？？原因：我们假设把这个异常处理掉，一种你就抛出新的异常处理，第二种空处理，第三种将异常处理信息带返回值。对于第一种，你的新的异常信息必须包括原有的信息，但是它有可能却给外界显示的信息太少了，包括真正原因。不过有时候这个方法仍然值得推荐，因为它使我们的异常信息可以更加明确，而这个明确是与调用接口或者是业务逻辑相关连。而对于第二种，杀掉异常，这对于维护人员，以及数据出错，会造成极大的损失，这种做法一定不要使用，因为它导致人家在出错的时候却不知道错在什么地方。而第三种，这样一返回将对代码的可读性与可维护性产生极大的问题。

 　　对于异常我认为，如果真的需要有一个异常抓取到，抓取到后直接throw，其代码如下：

try

{

}

catch(Exception ex)

{

     throw;//这里不可不要抛出ex，因为它查不到根源

}

 　　对于异常不得不说资源的释放,建议在可以预见使用using;因为它增长了代码的可读性,减少了必要的冗余,昨天我和一位群友讨论关于using在数据库链接使用using是否释放资源问题,现在我们来测试一个例子,以实际情况来说明问题,代码如下:

 

            SqlConnection con = null;
            try
            {
                using (SqlConnection con2 = new SqlConnection("server=.;uid=sa;pwd=234qwe;database=iFTS_Books;"))
                {
                    con = con2;
                    con2.Open();
                    throw new Exception("Exception");
                }
            }
            catch (Exception)
            {
            }
           

            Console.WriteLine(con.State.ToString());

如果输出是关闭,则说明是释放资源(这里有可能把它返回连接池,或者关闭,因为连接池windows自动管理),事实结果是close.不信你可以测试一下

　　对于web应用程序，可以使用应用程序事件，用于显示友好的提示信息

 

关于异常暂时写到这里，改天将写一编关于性能优化的方法，这个是主要找出性能问题所在，不对细节说明，因为细节网上太多了，写了浪费你我的时间