try/catch与性能
在程序中如何使用,什么时候使用try/catch
它对性能又有什么影响？
[解决办法]
你觉得有异常出现就用它.
这个没什么影响的...
反正你不手工捕捉,系统也会帮你自动捕捉的...
[解决办法]
当操作可能引发异常时使用啊，如数据库连接时，对性能没有什么影响吧，学习....
[解决办法]
try/catch是捕获异常用的，用于可能会出现异常的地方，当出现异常的时候对异常进行处理，它跟性能有关系吗？
[解决办法]
使用try/catch是影响系统的性能的，最简单的道理是我们一般把try块称之为监视块，你派个东西监视你的代码，这能不消耗额外的资源么？
在程序中如果能有其他方式避免异常，则需要考虑避免使用try/catch
比较典型的处理是，比如做类型转换的时候，用int.TryParse而不是int.Parse，这样就不用去捕获System.FormatException
如果你要处理 x/y这样的表达式，提前判断了y是否为0，就不用去处理System.DivideByZeroException
在使用数组的地方，使用 Length属性而不是固定值，可以防止System.IndexOutOfRangeException
但如果是我们的程序无法处理的问题，那么就必须使用异常处理了，必须你向用户的D盘写一个文件，用户可能没有D盘，可能D盘是光驱，可能D盘空间不够，这个不是我们的程序能解决的，就只能用异常处理了
最后，当项目比较大的时候，异常处理可能导致你无法找到你出错的地方。
所以，慎重使用异常处理。
[解决办法]
哇 好详细 晓习
[解决办法]
会在il多生成一些代码
不过这也是个度的问题
也不能因噎废食啊
[解决办法]
[解决办法]
http://181796968.blog.51cto.com/213419/41776
上面的文章可以参考一下
[解决办法]
4楼好象把整个事情说反了。
－－你派个东西监视你的代码，这能不消耗额外的资源么？
抛出异常是CPU内部的固有功能，当CPU计算或寻址出错时会产生一个硬件中断，中断程序会处理try/catch代码。所以完全不影响性能，并没有派个东西监视你的代码。
－－在程序中如果能有其他方式避免异常，则需要考虑避免使用try/catch
－－比较典型的处理是，比如做类型转换的时候，用int.TryParse而不是int.Parse，这样就不用去捕获ystem.FormatException
正好相反，在程序中应尽量使用try/catch，比如做类型转换的时候，如果自己编一段程序去判断原始数据的格式是不明智的，有些判断比较复杂(bouble、DateTime等等)，会浪费保贵的时间，还会影响程序的性能，还不容易把所有异常都考滤进来，比如咱们很少考滤内存够不够等等。
－－当项目比较大的时候，异常处理可能导致你无法找到你出错的地方。
当项目较大的时候异常处理显示的错误信息会帮助你尽快的找到出错的地方。
在程序中不仅要使用系统的异常，还有学会自己抛出异常。具体方法是在所有的子程序中抛出异常，在主程序中显示异常信息，这已经成为一种代码规范。以下是一个实例。
//主程序显示异常
function onSubmit()
{
try
{
VerifyPage();
Form1.submit();
}
catch( err )
{
alert( err.description );
}
}
//子程序抛出各种异常
function VerifyPage()
{
var strerr = "Please make your information completely.";
if( document.getElementById('TextBox3').value == "" )
throw( new Error( strerr ) );
isEmail( document.getElementById('TextBox3').value );
}
//子子程序抛出各种异常
function isEmail( stremail )
{
if( stremail == null || stremail == "" )
throw( new Error( "Please Enter the E-mail!" ) ) ;
if( stremail.length > 100 )
throw( new Error( "E-mail is too long!" ) );
var regu ="^(([0-9a-zA-Z]+)|([0-9a-zA-Z]+[_.0-9a-zA-Z-]*[0-9a-zA-Z]+))@([a-zA-Z0-9-]+[.])+([a-zA-Z]{2}|net|NET|com|COM|gov|GOV|mil|MIL|org|ORG|edu|EDU|int|INT)$";
var re = new RegExp(regu);
if( stremail.search(re) == -1 )
throw( new Error( "Is not validate E-mail address!" ) );
else
return
}
总之，使用try/catch能够使代码简捷明析，提高程序性能。目前已成为编程规范。
------解决方案--------------------
[解决办法]
补充一下，在子程序中抛出异常实际上是取代了过去的返回错误代码。另外finally很有用，多写就有体会了。
[解决办法]
调试的时候尽量不要try/catch,便于找出问题.
发布的时候为了控制一些不可预知的错误影响你的进程准确,再加上try.
程序正确运行时应该不收影响,一旦在某句中出现错误要跳到catch时,性能会明显有不同.(降低)
[解决办法]
抛出异常是CPU内部的固有功能，当CPU计算或寻址出错时会产生一个硬件中断
CPU是会抛出中断，但是注意的是：现在的高级语言都是有个监视异常的类，这
个是一直在系统的后台运作，也可以说windows自己就有这个异常判断，所以，
基本不会影响性能。
“抛出异常是CPU内部的固有功能”，这句话根本就是错的，汇编写的少吧？呵
呵，CPU只会运行和中断，在有就是现在的自我保护功能，压根就没有抛出异常
的功能（有就好了，上个月一同事就不会吧北桥给烧了，因为抛异常会中断的）。
[解决办法]
学习了！！
[解决办法]
学习了
[解决办法]
基本上，类库部分不应该“隐藏”异常，而顶多可以做点处理（例如数据库回滚等）然后继续向外抛出异常，直到整个系统的最终（客户端）界面上来显示异常信息并决定如何重新开始一个用户触发的操作。在类库中，用try/catch参与逻辑控制是不好的编程习惯。一旦遇到try/catch，首先应该要求程序员看看是不是应该自己去检测和处理错误而不是throw异常。如果程序员实在是搞不明白如何处理问题，才应该throw异常。这点上很少去把一点点效率之争放在第一位的。
[解决办法]
处理异常时，固然CPU有异常中断，但是也要上层各个层面的软件系统一层层处理，而不是CPU直接把机器给关了。因此还是要花非常多时间的。因此，只有程序实在是无助时才应该抛出异常给最终的客户端界面，通常不允许作为一种逻辑控制手段。
我几乎都是使用int.Parse而不是int.TryParse，这是因人而异的，通常就是要把问题抛出给最终客户界面，而不要求程序去自动处理异常。因为我大多数时候都不会去预先写好了文档要求程序此时必须处理什么样的错误，以及设计好处理错误之后的一切流程。如果没有设计好处理错误之后的程序流程，就不要为了效率而使用TryPase。
[解决办法]
明确地处理异常，即在Catch后边非常清楚地检测异常类型的细节然后处理，这尚可接受。一种很恐怖的编程手段，就是有些人写程序会写一个“万能”的异常处理程序，这看上去聪明的隐藏异常的办法其实是使得程序数据混乱、无法调试，这类程序直接应该被挑出来重写。
[解决办法]
尽量少用try..catch，如果预计到可能出错就多些点if..else
那样都比try..catch好
[解决办法]
try和 catch就是用ifthenelse实现的
[解决办法]
三个字： 不很好
四个字： 不特别好
五个字： 尽量少用好
[解决办法]
楼上的说得真好
哈哈,不用更好~
因为可以保证无错了嘛!~
[解决办法]
非常好 ，用得很舒服，因为就是 if then else
[解决办法]
抛出异常是CPU内部的固有功能，当CPU计算或寻址出错时会产生一个硬件中断，中断程序会处理try/catch代码。
这是我写的原话，这是最底层的抛出异常。“硬件中断”是计算机专业术语，意思是中断当前的指令流，执行另一段指令，并不是把CPU或计算机关了。
[解决办法]
继续进来学习
[解决办法]
第一次听说
一段代码 外 加了try ...catch...
还是提高 性能的做法...
只能等牛X 了.
[解决办法]
我觉得没有什么性能影响.
当然像4楼所说,提前把出错的东西判断,这样更好,这样就不会出现异常...
[解决办法]
没有try 和 catch的程序不是好程序
[解决办法]
------解决方案--------------------
学到了不少.....
[解决办法]
[解决办法]
针对非托管资源要注意使用try/catch，必须保证不管错不错都能关闭资源，如：文件的读写。
项目设置一个自己的调试标记。在try/catch的catch中作出调试与非调试处理，建议调试状态时把错误显示出来，这样可以让你在调试程序时更为方便，而且又不影响发布后项目的界面友好性，如ASP.net可以在web.config中作个调试标记，而发布后的web.config把标记设置为false或是去掉。(我是作asp.net的)
最后建议是能不用就不用。除非是无法避免或是很难判断是否会出错的情况下，如，数据库链接可能出错的各种失败。文件读取时可能出现文件锁定或是其它奇怪的错误等。
[解决办法]
我觉得从用户的角度来看,应该尽量少用try...catch.
太多的提示会让用户感到不爽.
[解决办法]
[解决办法]
一般涉及资源的地方都要用。
[解决办法]
学习了 从来没研究过这个问题
[解决办法]
[解决办法]
[解决办法]
那用户在一个必须输入数字的地方输入字符你不用try catch用什么？
[解决办法]
[解决办法]
捕捉异常不一定非要MessageBox.Show(e.Message)也可以干很多其他的事，
有时候我编的程序就是在等他出异常，当分支用了（尤其在数据类型转换的时候），不知道这算不算是个坏习惯
[解决办法]
在我刚开始写项目的时候很喜欢做异常处理，可以说不加try/catch就不舒服
现在也用，不过思路想法和以前不一样
1. 只有有可能出异常的地方放在try块，而不是一堆包进去
2. 能用代码去判断处理的，可以考虑不用异常处理
3. 有时候自己的方法中有异常，需要考虑是不是让调用者来处理，而不是自己去处理
[解决办法]
[解决办法]
[Quote=引用:]
4楼好象把整个事情说反了。
－－你派个东西监视你的代码，这能不消耗额外的资源么？
抛出异常是CPU内部的固有功能，当CPU计算或寻址出错时会产生一个硬件中断，中断程序会处理try/catch代码。所以完全不影响性能，并没有派个东西监视你的代码。
－－在程序中如果能有其他方式避免异常，则需要考虑避免使用try/catch
－－比较典型的处理是，比如做类型转换的时候，用int.TryParse而不是int.Parse，这样就不用去捕…
//我支持这个是对的，在你不确定是否有异常的时候就是应该用try/catch,特别是在数据库中
[解决办法]
支持你的说法。
try/catch
是很定不能提高效率的，其实程序产生异常是不可避免的，比如最简单的 空指针异常，
effective java 里说过 “永远不要相信你拿到的对象不是NULL”，但是在程序运行时
异常的概率是十分低的（除非你的代码有问题）所以我们没必要把所有代码都try/catch 起来。
程序会试运行，try/catch 这间的代码块。所以把最可能出异常的代码try/catch 是个好办法。
最好不要try/catch 很大的程序块。
[解决办法]
[解决办法]
[解决办法]
NET中的异常处理机制
１，CLR为每个进程创建一个异常信息表。
２，在表中，程序中每个方法有一个关联的异常信息数组。
３，若方法中有catch块，则数组中记录了调用异常处理所需的相关信息。
４，若方法没有catch块，则数组为空。
５，方法中发生异常时，在异常信息数组中搜索，确定哪个块引发异常。
６，若找到，则抛出Exception
７，没找到，则向上搜索方法的调用者，直至源头。
８，这些由下向上的搜索过程，其信息记录在一个堆栈中，称“异常堆栈”
[解决办法]
[解决办法]
其实TRY/CATCH主要目的是改善程序结构，当然结构好了，性能也就提高了。
如果这么说． 那用不用ＴＡＹＣＡＴＣＨ都一样反正代码写的好．性能肯定会提高
--总之，使用try/catch能够使代码简捷明析，提高程序性能。
我说的是 有ＴＲＹＣＡＴＣＨ 和 没用ＴＲＹ ＣＡＴＣＨ哪个快而已
[解决办法]
“在复杂系统里ＴＲＹ ＣＡＨＴＣＨ 是很消耗系统资源的
尤其是触发了ＣＡＴＣＨ的 看代码情况
一般速度比自己处理的慢了几倍”
你可以看看华容道与数据结构这个的代码和文章
[解决办法]
在 框架设计(第2版) CLR Via C# 19.9讲解了如何正确地使用异常，19.10讲解了性能考虑 有兴趣的朋友可以看看
[解决办法]
提高性能,当出现错误时出现有好的抛出异常的提示
[解决办法]
[解决办法]
MARK
[解决办法]
[解决办法]
恩。。。异常排除是有必要的。。。
[解决办法]
MARK
[解决办法]
try
{
//加代码
}
catch(Exception ex)
{
//添加你向用户显示的信息
}
finally
{
//无论是否异常都执行的代码
}
[解决办法]
[解决办法]
当操作可能引发异常时使用啊
[解决办法]