Comments on: Try/Catch Blocks Can Hurt Performance Significantly

By: Chinh Do

Chinh Do — Sat, 06 Feb 2010 16:37:12 +0000

Hi Derk: Thanks for your comment. I agree with you. My example is an example of bad exception handling, so definitely don’t do it like that. Chinh

By: Derk

Derk — Sat, 06 Feb 2010 11:20:04 +0000

The thing that I see missing in this discussion is that exceptions should only be used for _exceptional_ behaviour. In your example, Chinh, you’ve used exceptions for expected behaviour. In general, exceptions are a great thing, and they don’t affect performance. Just don’t write code that depends on them being called.

By: Dmitriy

Dmitriy — Tue, 15 Dec 2009 19:00:09 +0000

This is would be the best way to do this try catch block
w.Start();
int notFound = 0;
try
{
for (int i = 1; i <= 1000000; i++)
{
int value = numbers[i];
}
}
catch
{
notFound++;
}
this.label1.Text = “Elapsed: ” + w.ElapsedMilliseconds + “.”;

By: Chinh Do

Chinh Do — Wed, 26 Aug 2009 16:47:21 +0000

Hi thedudeewr: Thanks for you comment. The point of the ProgrammerHeaven article is absolutely correct… there’s no significant performance issue with one single empty try/catch block.

My main point was only to add “but be careful”… even if the empty try/catch block doesn’t impose any performance issue, we usually have some type of code inside the catch block… and that code may be an issue when it gets triggered, especially in a loop. That’s all.

Anyway, I guess I didn’t say what I wanted to say clearly. I can see how my post could be misunderstood as trying to refute the ProgrammerHeaven’s article.

By: thedudeewr

thedudeewr — Wed, 26 Aug 2009 16:08:10 +0000

sorry but while you might be true , youre not comparing apples to apples, you should take a class in algorithm analisys. the question is wheter ONE try catch hurts performance (and some memory) , and the article you linked answers this, only adds a litle more to memory and performance, if you insert it in a loop then u multiply this by n so then the algorithm goes to O(n), to prove your point you will have get as result a O(n^2) or higher to make your point.
what you are saying is like comparing creating one integer as opposed to creating integers inside a loop. but anyway good try.

By: Chinh Do

Chinh Do — Wed, 04 Feb 2009 14:08:38 +0000

Andrew:

I do not by any means recommend that try/catch blocks are avoided. I just wanted to stress that there IS a cost when an exception is raised. The programmers heaven article actually stated that as well.

Since you have a loop involved with your exception handling code, I think you are right to re-examine the exception handling code. I would carefully examine any possibility that the exception handling code may get triggered repeatedly. There’s really the only scenario where your performance can be degraded significantly.

Chinh

By: Andrew Ross

Andrew Ross — Wed, 04 Feb 2009 09:30:39 +0000

I came to this article after looking at the article from programmers heaven, looking to see if I should bother rewriting the search code for an application I have just inherited.

I was going to leave it as it was after seeing the programmers heaven article.
I didn’t like the try catches everywhere but I thought it wasn’t going to hurt so why bother. After seeing this article I’ll get to removing the try catches and just check to see if the row number exists.

Worst part is the methods that I’m going to rewrite are used in a loop.

Thanks for clearing that up.

By: chinhdo

chinhdo — Wed, 19 Nov 2008 14:09:18 +0000

#http://www.chinhdo.com/wp-includes/images/smilies/icon_smile.gif

posted on September 15th, 2008 at 12:21 am
# 14 On September 17th, 2008, Chinh Do said:

Tommy: Yes you are 100% right. My code example is not a very good one.

By: Chinh Do

Chinh Do — Thu, 18 Sep 2008 00:23:24 +0000

Tommy: Yes you are 100% right. My code example is not a very good one.

By: tommy

tommy — Mon, 15 Sep 2008 04:21:34 +0000

wouldn’t it just be faster to not do any of that code? Seems like if you skipped it all you could just avoid all the code and exceptions in the first place