经常看到同事这样写代码：
复制代码 代码如下:
DataSet QueryDB()
{
DataSet ds=null;
try
{
//do something
}
catch (Exception ex)
{
//这里要做日志记录
}
return ds;
}
这里有几个问题：
1：很明显，如果QueryDB方法发生了任何异常，客户端无法得知，例如客户端调用QueryDB方法，该方法返回了null，那这代表数据库里面没有这个数据呢？还是抛出了异常？
2：注释是不应该存在的，它应该被真实的日志记录代码给替代，例如Log.Write(ex);
3：该方法捕捉所有异常，这样任何异常都被捕获了，这对于开发很不方便，永远不要捕获你不能处理的异常。
4：为什么这样写代码？？解释是：真实用户不希望看到错误信息，初听起来，好像有几分道理，试想没有哪个用户会用你的软件，然后老是抛出个异常什么的，但是这是部署之后的事情啊，而不是开发的程序员不希望看到异常啊。在开发的时候，如果能够看到详细的异常信息，那么可以很快的改正，修复Bug，何乐而不为之呢？？
于是修改为如下：
复制代码 代码如下:
DataSet QueryDB()
{
DataSet ds = null;
try
{
//do something
}
catch (Exception ex)
{
Log.Write(ex);
throw ex;
}
return ds;
}
好了，现在异常总算被捕获了，并且也被成功了抛出来了。
这段代码还是有问题？？
在catch语句块中，throw ex; 最好修改为throw;
因为在.net中，异常都是不可修改的，每一次异常被抛出的时候，异常的堆栈跟踪信息都会被重置，
Throw 不会重置堆栈跟踪信息，但是throw ex;会重置。所以为了更方便的查找异常的抛出位置，最好使用throw 语句，而不是throw ex；否则clr会认为异常是在catch语句块中抛出的。
顺便再说一句，不要捕获你不能处理的异常，如果希望将来用户看不到异常信息，
大可以使用AppDomain.或者Application的全局异常处理。
【你是不是这样写异常处理代码的呢?】相关文章：
★ C#异常处理详解