个人觉得try catch语句是侦测语句。
try{
需要侦测语句
}catch(跟踪错误类){
错误操作语句
}
try侦测语句运行情况.
当侦测语句运行出错时,抛出错误类,然后根据错误类提供的信息,执行错误操作语句.
使用try catch语句效率低下我觉得有几个原因,首先由于程序需要进行错误侦测,那么执行侦测语句时需要更多的资源,其次,错误操作语句也要消耗相应的资源.
就我学到的编译知识，感觉TRY CATCH会小小影响编译的速度，因为翻译模式内要回填异常的处理地址，而在运行期间应该不会影响速度。对效率的影响不大，可以放心使用。因为就算你不写代码去捕获可能出现的异常，.net Framework在运行时也会帮你捕获运行时出现的异常，转向其异常处理程序，结果就是弹出对话框来提示你，我想大家在调试的时候都见识过吧。
另外，.net在产生异常时是逐步向外层查找处理程序的，就是说，如果当前函数中没有对异常进行处理，才查找调用当前函数的那一个函数，一直找遍整个应用程序，如果还没有，就交给runtime,在这种情况下，效率才是最低的，而且比较难于处理。
如果发生了异常,我认为捕获的越早效率越高,但往往我们需要在一个合适的层面上来捕捉,所以有一个平衡问题,还是得具体问题具体分析.
1、将预见可能引发异常的代码包含在try语句块中。
2、如果发生了异常，则转入catch的执行。catch有几种写法：
catch
这将捕获任何发生的异常。
catch(Exception e)
这将捕获任何发生的异常。另外，还提供e参数，你可以在处理异常时使用e参数来获得有关异常的信息。
catch(Exception的派生类 e)
这将捕获派生类定义的异常，例如，我想捕获一个无效操作的异常，可以如下写：
catch(InvalidOperationException e)
{
....
}
这样，如果try语句块中抛出的异常是InvalidOperationException，将转入该处执行，其他异常不处理。
catch可以有多个，也可以没有，每个catch可以处理一个特定的异常。.net按照你catch的顺序查找异常处理块，如果找到，则进行处理，如果找不到，则向上一层次抛出。如果没有上一层次，则向用户抛出，此时，如果你在调试，程序将中断运行，如果是部署的程序，将会中止。
如果没有catch块，异常总是向上层（如果有）抛出，或者中断程序运行。
3、finally
finally可以没有，也可以只有一个。无论有没有发生异常，它总会在这个异常处理结构的最后运行。即使你在try块内用return返回了，在返回前，finally总是要执行，这以便让你有机会能够在异常处理最后做一些清理工作。如关闭数据库连接等等。
注意：如果没有catch语句块，那么finally块就是必须的。
其中有两点值得注意下， 经常考的，无catch一定要finally,return在finally之后。