在try，catch块之外运行代码有没有任何性能优势？

Question

我很想知道是否应该最小化try/catch块内部的代码，或者它确实无关紧要。

public bool ObjectExists(string stringTest, string againSomethingElse) 
    { 
     if(true) {} 
     else {} //Code here is better/worst/same 
     try 
     { 
      //Versus code inside try/catch block 

     } 
     catch (Exception) 
     { 

      throw; 
     } 
    } 

Answer 1

在.net中，如果实际抛出异常，try/catch只会产生开销。因此，不要过于担心try中的代码的性能影响。只是不要将异常作为流量控制的一种形式。

Answer 2

我同意递归，但你可能想看看一个很好的解释： http://www.programmersheaven.com/user/pheaven/blog/175-Do-trycatch-blocks-hurt-runtime-performance/

基本上，有使用在try..catch没有问题，但是，我倾向于限制什么，我在他们的我认为依赖它们是不好的做法，而不是尽你所能去确保异常不会抛出，因为异常会很昂贵，所以，在获取它的长度之前检查该字符串是否为空。

Answer 3

我同意上面的内容，但是你不应该把你的整个代码块放在try catch中，让它抓住formatexception或null引用。你应该为这些编写代码并自己处理它们。

我不知道有多少次我看到：

try { 
Request.QueryString["id"].ToString(); 
} 

显然，一个空引用如果id为null，所以检查它是否为空，不要试图/抓住它。

Answer 4

下面是解决此问题的正确方法。

首先编写代码，以便异常处理是正确的。始终保持正确。

然后设定合理的，以客户为中心的绩效目标。然后测试你的程序。然后，如果你没有达到你的目标，使用一个分析器来找到最慢的事情。如果一些奇怪的巧合最慢的事情碰巧是你正确的异常处理，那么你应该考虑异常处理的性能成本。