Don’t use exceptions for flow control

I just read a blog entry titled A word from the “Wise”: Don’t Use Exceptions on Alex Papadimoulis’ weblog. He describes in great length how a so-called MVP had told him that using exceptions was a bad idea and continues to prove in ten points why he doesn’t believe it.

Well, not. The only thing Alex proves is that he didn’t remotely understand what that MVP guy was (probably, I’m only guessing here, of course) talking about. The most important hint is one that Alex misses completely: The MVP said not to use exceptions, but instead use return codes… now, what might that have been about?

The answer is simple, and it doesn’t take an MVP to tell anyone… a simple Google search says enough about this. Exceptions are not a tool for flow control!

What does this mean? Simple, for example: If you are going to divide something by something else, it’s a much better idea to check the divisor for zero than to catch a DivideByZeroException. That’s what the MVP dude meant when he was talking about exceptions killing performance: it’s a simple processor instruction to check a variable for a specific value, it’ll take thousands of additional cycles to throw an exception and catch it, the result is the same.

An exception is meant as an instrument to signal that your application’s flow has been broken. That’s the one most important feature of the exception handling subsystem: it works across all boundaries of application flow. It’s neither designed nor very useful for any situation where the state of the application is known.

Rule of thumb: if you expect that an error may occur in any specific line of code, and you are going to implement alternate handling for that particular case, don’t use an exception. That’s not an unexpected application state and shouldn’t be handled with an exception.

And then, if you’re going to measure executing speed, at least do it properly. Run a profiler and look at the number of method calls that take place in that small test program of yours. And then imagine, how fast would the .net framework be if some guys who work at MS didn’t know when (not) to use exceptions? Who says that your method is only ever going to be called ten times in a row? What’s your excuse why you didn’t write code that’s as fast as it can be? You laughed when someone tried to explain it to you?

2 Comments on Don’t use exceptions for flow control

  1. I completely agree with you, but I have been “dealing” with it in one (quite common) scenario:Int32.Parse().In ASP.NET, when you request a querystring variable it comes back as a string. A lot of times we expect an integer, but you obviously cannot trust it. int myIntVal = Int32.Parse( Request.QueryString[“someVar”] ); //this could throw an exception, in fact quite easily. Whidbey brings us Int32.TryParse(), but for our 1.1 apps this doesn’t help us.What would you suggest? Regular Expressions?


  2. Hi Ben – you are right, this is one of the unfortunate situations where the exception you want to avoid is not thrown from your own code, so it’s not really in your hand to do anything about it. What would I suggest? Well, first of all: “Don’t use exceptions for flow control” is a guideline, a goal you try to reach, not a low set in stone. So if there are situations where you find that using exceptions is actually the best, or the only, approach to a specific problem, you should probably just use them. In this case, I’d suggest use them, make a TODO comment in your code and replace that code with a call to TryParse when you change to .NET 2 at the earliest possible point.Using regular expressions is an alternative, of course. Or even, for simple numeric values, to code up your own validity check – checking whether a string comprises of a number of numeric digits is not a hard task. When things are more difficult, the code-it-yourself approach is not so good, and I have never tested how the performance of regular expressions stacks up against catching an exception in a case like this. It’s certainly a nicer way to implement the functionality, but then regular expressions are a big and mighty tool to call for when all you need is a simple numeric validity check.


Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s