关于异常处理和正常处理哪个更耗费资源

[cejay]

如题：

代码一：

if (i != null)
            {
                if (i == 0)
                {
                    //正常执行的代码
                }
                else
                {
                    //跳出
                }
            }

代码二：

try
            {
                if (i == 0)
                {
                    //正常执行的代码
                }
                else
                {
                    //跳出
                }
            }
            catch (Exception)
            {
                //跳出
            }

上面的两段代码哪段更耗费资源？

[bancxc]

在不出错的情况下 1多了一次判断
出错的时候二多了异常处理

[捷哥1999]

个人感觉，出现异常后，异常信息需要被保存，应该会更加耗费一点资源。
所以第一个写法，避开了null下的情况。
前提是你的i是引用类型，如果是基本类型，则没有必要这样比较了。

[cejay]

前提是只有null和int两种情况，我也是觉的应该用异常比较耗费资源，但是不知道是不是

[兔子-顾问]

在不出错的情况下。没什么区别。

[cejay]

楼上除了我自己，全是技术牛人呀。

[以专业开发人员为伍]

跟“更耗费资源”有什么关系？

你如何理解异常？你调试吗？你维护一个异常堆栈并在各种表现层以不同的形式捕获和处理异常吗？

你把异常当作代替退出的方法，或者用退出就权作抛出异常了，看不出有什么用？！仅仅因为耗费资源少就决定用它？那么除了进行加减法以外什么代码也别写，因为动不动就会有更加耗费资源很多被的代码写出来啊！

[cejay]

[Quote=引用 6 楼 sp1234 的回复:]

跟“更耗费资源”有什么关系？

你如何理解异常？你调试吗？你维护一个异常堆栈并在各种表现层以不同的形式捕获和处理异常吗？

你把异常当作代替退出的方法，或者用退出就权作抛出异常了，看不出有什么用？！仅仅因为耗费资源少就决定用它？那么除了进行加减法以外什么代码也别写，因为动不动就会有更加耗费资源很多被的代码写出来啊！
[/Quote]

我是这样想的，如果能用多个判断来避免异常好，还是直接不用多个判断直接加异常处理好呐？

[祭礼]

个人感觉 1 好

[兔子-顾问]

[Quote=引用 7 楼 cejay 的回复:]
我是这样想的，如果能用多个判断来避免异常好，还是直接不用多个判断直接加异常处理好呐？
[/Quote]

异常捕获2个情况下用
1.软件尚未发布，某些可能有问题的地方，先加上，方便判断错误，当错误出现了。记录日志的方式替换报错退出。
2.某些必然发生的异常，例如线程操作ui界面，界面的关闭可能会在线程的InvokeRequest判断之后发生，但可能早于Invoke调用，所以线程中正常的可能会有InvalidOperatorException出现，这种必然的可能，可以用异常捕获，避免软件报错退出。

[兔子-顾问]

如果你认为异常是用来替换你使用变量前的参数检查。这样的偷懒行为最终会让你的软件很乱，难以维护的。

[fengling2001]

学习了~~~

[cejay]

[Quote=引用 10 楼 wuyazhe 的回复:]

如果你认为异常是用来替换你使用变量前的参数检查。这样的偷懒行为最终会让你的软件很乱，难以维护的。
[/Quote]

学习了，您的意思就是能用判断自己处理所有出异常的信息就要自己判断，能自己判断的话就最好不要用异常处理了是吧

[kolosi]

不管性能如何，这个用法就是错的。
try catch是用来抓异常的，你这样如果循环里出错，当软件规模变大时，会变得非常难调试。

[cejay]

[Quote=引用 14 楼 microtry 的回复:]

1、设好最后的防线:只在应用程序边界Catch，比如UI的事件,一旦Catch，不再throw；
2、如果i==null经常发生，并且是一种“正常情况”，那么楼主第一种做法是较为合理的，
这种情况下引发异常就会造成性能问题；
3、全线进攻:用断言拦截所有你能遇见的"不正常"情况,避免系统引发标准异常,
楼主的代码应该改写成进攻性的，
也就是说，如果i==null这种情……
[/Quote]
谢谢你啦

[缪军]

1、设好最后的防线:只在应用程序边界Catch，比如UI的事件,一旦Catch，不再throw；
2、如果i==null经常发生，并且是一种“正常情况”，那么楼主第一种做法是较为合理的，
这种情况下引发异常就会造成性能问题；
3、全线进攻:用断言拦截所有你能遇见的"不正常"情况,避免系统引发标准异常,
楼主的代码应该改写成进攻性的，
也就是说，如果i==null这种情况是“不正常的”，并且你能预见到这种不正常情况，
那你最起码应该报告“自定义异常”或者一个特定的异常（因为是你能预见的）,
而不应该由系统引发一个标准异常.

代码如下：

if (i == null)
{
    //在这之前你首先应该写一个自定义异常类,并且拥有这样的构造器MyException(string pErrMsg)
    throw new MyException("出现null异常,变量i不能为null");
    //当然也可以:throw new ArgumentNullException("变量i不能为null");
}
else
{
    if (i == 0)
    {
        //正常执行的代码
     }
    else
    {
        //跳出
     }
}

请参考MSDN相关链接:
异常引发：http://msdn.microsoft.com/zh-cn/library/ms229030(v=VS.80).aspx
异常和性能：http://msdn.microsoft.com/zh-cn/library/ms229009(v=VS.80).aspx
处理异常的最佳做法：http://msdn.microsoft.com/zh-cn/library/seyhszts.aspx

综上所述:
1、异常是报告错误的标准机制。应用程序和库不应使用返回代码来传递错误信息；
2、对于大多数常见方案来说，异常对性能的影响不会构成问题；
2、性能问题是由于不合理的设计方案造成的，不要由于担心异常可能会对性能造成不良影响而使用错误代码

[缪军]

[Quote=引用 15 楼 cejay 的回复:]
[/Quote]

只要还有人能注意到，我就很高兴啦

[兔子-顾问]

[Quote=引用 16 楼 microtry 的回复:]
只要还有人能注意到，我就很高兴啦
[/Quote]
我也有阅读结贴帖子的习惯 ：）
有空还是要阅读一下你提供的链接，之前c++的时候看过异常处理的部分，太长了。.net开发的时候就下意识的保持习惯，尽量少用，迫不得已的时候才使用异常捕获。c++的异常处理很复杂，而且注意事项很多。还不许嵌套。嵌套就会丢掉其中的内层异常。

[缪军]

[Quote=引用 17 楼 wuyazhe 的回复:]
[/Quote]

呵呵,逍遥兄,你知道吗,.net首先吸引到我的就是它的异常处理机制,
把整个安全架构确定以后,异常处理中心可以慢慢改进,而不影响所有的代码,这种体验确实非常棒,
微软确实为程序员做了很多,
而更值得我们学习的还是这种思维模式,
如果我们的用户在使用我们的软件的时候能感受到:"软件开发者为我们做了很多",那是多么的棒啊

[兔子-顾问]

恩。恩。晚上回家仔细看看这个。谢谢