Comparing apples to pine cones.

The original article stated that the try catch construct didn't add significant overhead which it DOES NOT. In your code example it is the error being thrown and handled that causes the delay not the try catch itself, if you did not cause the error to be thrown the performance would be close to the performance without the try catch (In my code, I have been unable to measure the difference in milliseconds).

misleading and incorrect article.

Schwankie is right, here is a quick test I did using the methods in the linked article:

Emptry dictionary, so there is an exception thrown on each iteration:
No try/catch: 0.0004162 seconds
Try/catch in for loop: 58.59 seconds

After I filled the dictionary so no exceptions will be thrown:
No try/catch: 0.0005534
Try/catch in for loop: .0065167

This is on 10,000 (ten thousand) iterations in the for loops.

When I moved up to 10,000,000 (ten million, the most I coudl get without OurOfMemory exceptions) loops I got:
No try/catch: .499
Try/catch: .564

I also agree that we're not comparing the same thing here!
;(

This article is simply idiotic.

<i>Try/Catch Blocks Can Hurt Performance Significantly</i>

Throwing Ten Thousand Exceptions Can Hurt Performance Significantly
-there, i fixed it for you

static void Main()
{
int myNum;
int notFound = 0;
int max = Int16.MaxValue;
Random r = new Random();
Dictionary<int, int> numbers = new Dictionary<int, int>(max);
Stopwatch w = new Stopwatch();

// Give us some numbers to work with
for (int i = 0; i < max; i++)
{
numbers.Add(i, r.Next(Int32.MaxValue));
}

w.Start();
for (int i = 0; i < numbers.Count; i++)
{
try
{
myNum = numbers[i];
}
catch (KeyNotFoundException)
{
notFound++;
}
}

w.Stop();
Console.WriteLine(notFound);
Console.WriteLine("Elapsed: " + w.ElapsedMilliseconds + ".");
Console.ReadLine();
}


Output:

0
Elapsed: 0.

It happened so fast that I thought I did something wrong.

Thanks for everyone's comments. My example is a little bit on the extreme side but it's to prove a point: that bad/incorrect use of structured exception handling CAN lead to performance problems.

The Programmers Heaven article does say in its conclusion that the performance hit of a try/catch block that never handles an exception is virtually nothing. I totally agree with that.

However, by virtue of having a try/catch block, there is the possibility that it WILL catch and handle an exception :-). I also think that many programmers will read the PH article and come out with the wrong conclusion that they should never worry about performance issues with exception handling.

The article does make the point that using try/catch blocks as program flow is bad design.
I think we can all agree that checking for an exception case and handling it is the best way to write code.

public void doSomething(object something) {
if (something == null)
return;
}

is ALWAYS more efficient than:

try {
doSomething(something1);
} catch (Exception e)
{
wtf(e);
}

Needless to say I think this subject has already been well covered now.

Tagged appropriately.