sp.net 2.0以后，框架将这个检测转换过程封装到Int32.TryParse方法中，再也不用蹩脚的try/catch来处理了。

还要补充一点，就是finally中的代码是始终保证运行的，所以留给大家一个问题，下面代码执行后a的值是多少：

int a = 2;
try
{
    int i = Int32.Parse("s");
}
catch
{
    a = 1;
    return;
}
finally
{
    a = 3;
}

小节：本文主要对异常处理的3个常见误解进行了纠正。撰稿仓促，如有疏漏，烦请指出。

参考文献：

http://msdn2.microsoft.com/zh-cn/library/system.exception(VS.80).aspx
http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/cpguide/html/cpconexceptionsoverview.asp
《CIL Instruction Set Specification》
《Applied Microsoft.NET Framework Programming》

 评论：

# re: 关于.NET的异常处理的几个误区[未登录]2007-08-05 20:15 | Lucifer
这个在Jeffery Richter的CLR via C#中讲解的足够清楚，大家可以去阅读一下！
很遗憾的是楼主的
catch(Exception e)
{
throw e;
}
在.NET 1.x版本中不能捕捉不符合CLS的异常。而在.NET 2.0中虽然能够捕捉所有异常，却会改变异常的起始点。FxCop会报告这是个错误。

如果你要重新抛出异常，建议采用
catch(Exception e)
{
throw;
}
上面的这段代码虽然也会修改异常的起始点，但是CLR却知道原始异常被抛出时的堆栈位置。

此外，异常带来的好处远远超过它会带来的性能损失。    # re: 关于.NET的异常处理的几个误区2007-08-05 20:32 | 寸芒
楼上的，我有异议，虽然throw e 是抛出新的异常，但是这个新的异常对象还是原来的异常。就算你在这个子catch里改变了这个异常！    # re: 关于.NET的异常处理的几个误区[未登录]2007-08-05 20:52 | Lucifer
@寸芒
我同意你的观点。
实际上，这两段代码的区别就在于CLR如何确定异常抛出的起始点。
但是，如果你要用throw e。FxCop就会报错。

所以，还是推荐
catch(Exception e)
{
throw;
}
而这种捕获所有异常再次重新抛出的行为是非常罕见的。  
  # re: 关于.NET的异常处理的几个误区2007-08-06 08:35 | Anders Cui
建议：
尽量不要catch像Exception这样的通用异常类;
使用throw来维护异常堆栈;
如果要抛出新的异常，可以将原来的异常定为内部异常;
使用try-parse模式时注意，如果因为try操作之外的原因导致操作失败，仍应抛出异常;  
  # re: 关于.NET的异常处理的几个误区2007-08-06 09:35 | Bruce Lee
异常处理一直用不好，具体是什么，希望总结下。  
  # re: 关于.NET的异常处理的几个误区2007-08-06 10:08 | Truly
呵呵，首先看到大家踊跃发言，甚感欣慰，有些人也做了深入思考，这都很好，起到了抛砖引玉的效果。

顺便说一下，上面2位的意见基本上跟我的文中所述并没有什么出入，避免使用，改变异常位置，避免捕获所有异常等等这都是大家认可的观点。

另外，CLR via C#事实上就是我文中提到的参考文献中的《Applied Microsoft.NET Framework Programming》，在撰写此文的时候，我又再次审读了异常处理一章，不过还是谢谢你的留言。

同时，我也注意到Asp.NET 1.x到Asp.NET 2.0以后，异常有所不同，这一点我在测试那段代码的时候也注意到了，但是具体细节我没有去深究。  # re: 关于.NET的异常处理的几个误区2007-08-06 10:35 | Truly
对于一篇技术文章而言，能够留给读者一些思考空间是非常好的，显然本文达到了这一目的。对于技术，我也力图避免