Another performance query: What is the cost of an arbitrary try-catch? To your right, you should see the results.
Note that it took 2.5 times longer to execute the same code when it was inside a Try-Catch-block even though
No exception was thrown.
Don't get me wrong - the cost is often worth it. However, given the cost, it is wise to study exactly what Exceptions can be thrown in what scenarios, rather than just sprinkle your code with Try-Catches everywhere.
The code that was executed, was:
Private Function WithTryCatch() As Integer
Dim number As Integer
For index As Integer = 0 To CInt(Integer.MaxValue / 2)
Try
number += 1
Catch ex As Exception
End Try
Next
Return number
End Function
Private Function WithoutTryCatch() As Integer
Dim number As Integer
For index As Integer = 0 To CInt(Integer.MaxValue / 2)
number += 1
Next
Return number
End Function
Another performance query: What is the cost of an arbitrary try-catch? To your right, you should see the results.
Note that it took 2.5 times longer to execute the same code when it was inside a Try-Catch-block even though No exception was thrown.
Don't get me wrong - the cost is often worth it. However, given the cost, it is wise to study exactly what Exceptions can be thrown in what scenarios, rather than just sprinkle your code with Try-Catches everywhere.
The code that was executed, was:
Comments
If you move the try catch outside the loop (as you would, if you code like you should), is the result the same?
If you actually do anything that is representative of where you typically WANT to catch errors on a functional level, for example database connecting, file writing, WS-calling, etc, is the performance hit the same?
I know you are trying to prove a point, but your code here is simply not representative of what anyone would do if they are not clinically insane ;)
/Anders
I've discussed with Sami, and in fact we are in agreement. I had just misunderstood what he was trying to say with this article.
I thought he meant that try-catch was bad performance wise. What he meant was try-catch CAN be bad if you use it wrong, I.E sprinkle every line of code with a try-catch.
(The code above creates what? 1 billion try-catch blocks?)
In that, we are in total agreement. In fact, I've read that this is EXACTLY what On Error Resume Next does in VB .NET. It wraps each line it its own try-catch when compiled, thus actually causing this kind of scenario.
I've not verified this myself though, but it would be interesting to see the same comparison made with On Error Resume Next.
/Anders
Oh, by the way. I AM a mean, mean little man.
Of course the CLR or Compiler (I don't know which, and I don't really care) optimizes the try-catch inside the loop... it doesn't really matter if you place it inside or outside in this case, from a performance standpoint.