对try...catch...一些总结

如果使用了“Try-Catch”，且捕获到了异常，CLR做的只不过是遍历Exception Handing Table中的Catch项；然后再次遍历Exception Handing Table中的Finally项，所用时间几乎都花费在遍历Exception Handing Table上；而如果没有捕获到异常，CLR只是遍历Exception Handing Table中的Finally项，所需时间微乎其微。

而“Try-Catch”遍历后的执行对应操作所用时间，则根据你的具体代码所定，“Try-Catch”引起的只是监控与触发，不应将这部分的代码时间也算“Try-Catch”的消耗。

    一般建议有以下几点准则：

    1.尽量给CLR一个明确的异常信息，不要使用Exception去过滤异常

    2.尽量不要将try…catch写在循环中

    3. try尽量少的代码，如果有必要可以使用多个catch块，并且将最有可能抛出的异常类型，书写在距离try最近的位置

    4.不要只声明一个Exception对象，而不去处理它。这样做白白增加了Exception Handing Table的长度。

    5.使用成员的Try-Parse模式，如果抛出异常，那么用false代替它

     6.如果是try...catch中套着try...catch，异常处理机制是从内部的try...catch...往外部抛的，最先是在内部进行捕获、处理。

  7.尽可能的考虑到可能存在的异常并进行处理，尽可能的少出现异常或不出现异常。

以下摘自百度文档：

问题1:当一段代码被try块包围后与不加try时在没有异常发生的情况下,执行过程是否有区别? 

问题2: 如果有区别,那么这样的区别对性能的影响有多大呢? 

问题3: try的代码究竟做了些什么?他对代码做的是每次执行时监视还是以类似中断的的方式,当出现异常时主动调用什么过程转向异常处理.? 

问题1的回答: 

①: try{}部分和不加try/catch语句块的效率几乎一样, catch{}部分似乎需要100倍以上的时间 ,所以只要不把try{}catch{}作为你的程序的逻辑,这种设计就是合理的. 

②:从我的经验看来，在 try 中的代码和在没有 try 的情况下的效率是一样的，没有影响。

 

问题2的回答: 

①当同一类型的异常被第一次抛出的时候，明显可以感到效率的降低；但其后再抛出就没什么感觉了。还是什么文章中看到过这样的说法：CLR的异常处理机制相比C++要高效很多。 

②:就我学到的编译知识，感觉TRY CATCH会小小影响编译的速度，因为翻译模式内要回填异常的处理地址，而在运行期间应该不会影响速度 

③:没什么大的影响，对现在的机器配置来说，这点影响微不足道 

④:对效率的影响不大，可以放心使用。因为就算你不写代码去捕获可能出现的异常，.net Framework在运行时也会帮你捕获运行时出现的异常，转向其异常处理程序，结果就是弹出对话框来提示你，我想大家在调试的时候都见识过吧。 

  

问题3的回答: 

①:从硬件角度讲，异常和中断是同样的机理，都是在满足一定的条件的时候，由软件和硬件触发，并通过向量转到相应的处理程序。因此，异常在没有被触发的时候，应该是不会对性能造成影响的。  

另外，.net在产生异常时是逐步向外层查找处理程序的，就是说，如果当前函数中没有对异常进行处理，才查找调用当前函数的那一个函数，一直找遍整个应用程序，如果还没有，就交给runtime,在这种情况下，效率才是最低的，而且比较难于处理。 

②:如果发生了异常,我认为捕获的越早效率越高,但往往我们需要在一个合适的层面上来捕捉,所以有一个平衡问题,还是得具体问题具体分析.