使用保护条款或捕获异常更好吗?

时间:2013-05-10 14:31:08

标签: c# java exception

使用guard子句防止异常或捕获异常是否更好? 有最好的做法吗? 这两种方法的利弊是什么?

例如,这更好:

try
{ 
    param=myArray[3];
}
catch (IndexOutOfRangeException e)
{
    do something...
}

或者这个:

if(myArray.Length < 4)
{
    do something...
}
else
{
    param=myArray[3];
}

谢谢大家的答案:)

4 个答案:

答案 0 :(得分:17)

使用保护子句 - 捕获异常会导致高运行时成本,并且通常为了提高可读性,您应该仅对错误条件使用异常,而不是正常控制流

答案 1 :(得分:17)

  

使用guard子句防止异常或捕获异常是否更好?

如果索引超出范围的“愚蠢”例外,则始终为前者。

在“外生”例外的情况下,总是后者。

  

两种方法的正反两用?

在骨头异常的情况下,后者只有缺点。他们是:

  • 与测试相比,例外非常昂贵
  • 例外旨在模拟特别罕见的控制流情况;如果潜在地访问索引超出范围正常,则不要编写异常处理程序。
  • 即使处理了异常,也会将异常报告为侦听器的“第一次机会”异常。许多系统 - 例如ASP--监听第一次机会异常,记录所有这些异常,并将产生大量异常的组件视为 buggy ,因为它们是 。 (我曾经在ASP的公共代码路径中引入了故意的第一次机会异常,一天后,我听到了男孩的故障。这些越野车子系统测试变得疯狂。)
  • 有一些例外,我称之为“愚蠢”的例外 - 空取消引用,索引超出范围等等 - 这是因为它们很容易避免并且表明失败如此明显很危险他们应该总是被视为致命错误并且从不处理(除非“处理程序”在关闭进程之前记录它们。)不要处理错误,消除错误< / em>的。

最后,你应该阅读我关于这个主题的文章。

http://ericlippert.com/2008/09/10/vexing-exceptions/

答案 2 :(得分:4)

Guard子句。您永远不想将try / catch用于控制流程。捕获异常是昂贵的,应尽可能避免。

答案 3 :(得分:3)

如果可以防止异常,请阻止它。总是

捕获和处理异常是昂贵的,不应该用于正常的控制流程。守卫很便宜。