在.Net中处理异常应注意的问题

     我们在编写程序时总免不了和错误打交道，在结构化时代，常用的做法是用返回值来表达是否出错，到了OO时代，我们可以使用异常来表达错误，但如果使用不当，就不能达到应用的效果。请看下面的例子：     

F1()
{
  try
  {    
    F2()
    
  }
  catch(Exception ex)
  {
    throw ex;
  }
}

     这种代码在程序中经常见到，有什么问题？

     问题很严重，首先代码中的try catch的使用毫无意义，只会损伤程序性能，因为异常发生时如果不做任何处理，会自动向调用堆栈的外层抛出；其次，如果真的发生了异常，原始的异常对象的调用堆栈将从throw ex 开始算起，更深层的堆栈将会丢失，这会给我们找出错误的原因带来困难。

      有人还可能这样写：

try
{
  F2();
  
}
catch
{
  throw;
}

     这种写法有所改善，但也有问题，F2()中如果出错，这时候F2()函数内部更深层的堆栈并没有丢失，但这个函数本身在错误堆栈中的位置却变为throw这一行，而不是原本的F2();这一行，即丢失了此函数中发生错误的准确位置。

     针对以上的问题，我推荐的使用方法如下：

try
{
  F2();
  
}
catch(SqlException ex)
{
  DoSomethingToRecover();
  throw new MyException("My Message", ex);
}

     下面给出我的异常处理建议：

     1. 不能处理的异常尽可能不要捕捉, 除非在catch块中必须要做一些恢复或日常记录，在这种情况下总是抛出新的异常，并将原始异常作为内部异常；

     2. 尽可能只捕获特定的异常，而不要捕获Exception异常本身；

     3. 在出现错误的情况下用异常而不用返回值来表达错误，这样代码会更简洁；

     4. 不要使用异常来表达正常的逻辑，比如用户登录验证失败就不应该使用异常；

     5. 异常日志的记录应该放在分层的边界处，比如服务层，层的内部一般不需要记录日志。