关于.NET中TryCatch性能问题
记得以前做项目的时候,有人和我说过,如果对一段代码的TryCatch性能会低于对于封装这段代码的函数进行TryCatch的性能
则:
(1)
void DoSomething()
{
try
{
//Do something
}
catch Exception ex
{}
}
try
{
DoSomething()
}
catch Exception ex
{}
------解决方案--------------------原则上是性能不是很好的,不过还要看
代码是什么样的或写的如何,这个还是要做测试的;
还有为了不用 try 而浪费的时间,成本等等
主要还是要看什么场合的先说;
------解决方案--------------------能不用try catch就能避免的异常,绝对不要用try catch
------解决方案--------------------
------解决方案--------------------try - catch 是用来捕获异常的,比如项目中的数据库操作,文件读写操作等等。没必要对 try - catch 有任何不适。
当然,绝对不要乱使用 try - catch,不然你的项目总是抛异常,依靠异常来做所有的错误捕获操作是不好的习惯。比如,有一个界面需要用户输入数据,并且对用户输入的数据进行检查后保存进数据库,那么我们手工的做检查,比直接不做检查保存进数据库,依靠数据库的约束和主外键设置来对数据的合法性进行检查就要好很多。这样,就会在保存数据库之前排除掉很多可能导致错误的异常。太多的异常抛出不但会影响性能,而且也绝不是一个良好的编程习惯。
总结,try - catch 本身并不会很大地影响性能,应该说可以忽略它的存在。但是抛出很多异常就不是一个好现象,靠异常来检查所有的错误操作就绝对不好,它会影响性能,并导致不好的代码。
------解决方案--------------------的确会降低性能!能不用尽量不用,可以用using代替。
------解决方案--------------------除了表现层或其他宿主程序,原则上都应该尽量throw exception而不要做try catch
至于try里面是一行代码和1w行代码,是代码还是函数都没有区别
至于性能,可能就是构造错误堆栈会产生区别
除非是在实时系统中,才有应用场景需要考虑能够多快的catch到exception进行处理
------解决方案--------------------try抛出的是对象,不是字符串,你想想,从产生对象、再到遍历错误树,那一项不占内存,那一项不是吃CPU的大手笔?