Question

有没有人在try catch中执行null测试与包装代码的指标？

我怀疑null测试效率更高，但我没有任何经验数据。

环境是C＃/。net 3.x，代码比较是：

Dude x = (Dude)Session["xxxx"];
x = x== null ? new Dude(): x;

与

Dude x = null;
try {
    x = (Dude)Session["xxxx"];
    x.something();
} catch {
    x = new Dude();
}

在try catch中包装有什么好处吗？

Answer 1

如果null是可能的预期值，则测试null。如果您不喜欢null测试并且具有默认值，则可以使用null coelescing运算符来设置默认值：

// value is (Dude)Session["xxxx"] if not null, otherwise it's a new object.
Dude x = (Dude)Session["xxxx"] ?? new Dude();

保存try / catch for Exceptions（真正意外的事件）。

Answer 2

如果您正在寻找紧凑型代码，您可以：

Dude x = Session["xxxx"] as Dude ?? new Dude();

??运算符将返回两个值的第一个非空值（如果有）。

由于

Answer 3

我认为这将是最快的路线：

Dude x = (Dude)Session["xxxx"] ?? new Dude();

?? operator是一个快捷方式，用于在您想要指定特定值（如果它为空）时进行空检查。

无论如何，异常最终不仅会创建一个新对象，而且还会生成一个堆栈跟踪，从而减慢速度。

Answer 4

异常会占用额外的内存和时间。如果它是一个可能的值，那么测试null总是更好。

Answer 5

另一件事是要考虑它只是更少的代码和更可读的空测试。通常使用try / catch块为正常情况下的代码添加基本上没有开销，但是当触发异常时它非常昂贵。

Answer 6

我同意@Justin Niessner。此外，您可能希望阅读此article，其中显示了一些有趣的观点。

Answer 7

您不应该在程序的正常代码路径中使用try / catch。如果你这样做，你将创建垃圾收集器需要处理的常量垃圾。更好的是只测试null。

Answer 8

在这种情况下异常应该可以正常工作，但我相信数字＃1是最好的方法。异常不应该用作If / else语句，异常会引发错误，这会占用比第一次比较更多的系统资源。

Answer 9

永远不要使用程序控制流程的异常。你想要创建异常的唯一一次是，如果(Dude)Session["xxxx"];为null是因为停止你所在方法的运行。即，如果一个空值会阻止该方法成功完成它的功能叫做表演。在你写这个问题的时候，如果在这种情况下你需要做的就是继续创建一个新的Dude（），那么情况并非如此，所以不保证例外。

Answer 10

对例外情况使用例外 - 不是正常的程序流程。

如果你不得不做很多空检查，请考虑使用Null Object Pattern而不是使用实空值来表示可能具有默认行为的不存在的值。

在我开始使用Objective-C之前，我总是对Null对象模式有点怀疑，因为它是内置行为。它确实清理了很多代码（当然，它仍然不合适）。

Answer 11

由于您只想检查null，这就是您应该做的。它比捕获异常更有效。

此外，通过捕获异常，您应该非常具体，只能准确捕捉到您的期望。如果你发现任何类型的异常，你就有可能发现你没有预料到的错误并以错误的方式处理它们。

null test与try catch

11 个答案: