Taking exception

*WARNING* Geek rant ahead

So, I'm nipple deep in troubleshooting some craptacular code when I run up against my arch-nemesis, the Try Catch block that consumes the exception. See, we 'outsource' our code to various other countries because you can get 30 of them for the cost of one of us, and much like enough monkeys on enough typewriters will eventually churn out all of Carrot Top's jokes in pig latin, eventually these 'developers' crank out code that somewhat runs.

In computer terms, an Exception is a condition that changes the expected flow of code. For example if I try to access a file that isn't accessible, divide by zero, or touch memory I have no access to, an exception is thrown. Exceptions tend to have a bunch of nasty looking code that shows the call stack at the time the exception was thrown, and is something you generally do not want your end users seeing.

You can surround your code with a Try Catch statement if you know ahead of time that some of the code you're writing might throw an exception, then handle the exception in the Catch statement

try
{
   OpenFile();
}
catch (FileNotFoundException ex)
{
   //since the file doesn't exist, create it so we can work on it
   CreateNewFile();
}

In this pseudo-code example, we try to open a file, knowing that it might not exist. If the exception is thrown that the file doesn't exist, we 'correct' that and create it. Now, in this code if a "AccessDeniedException" is thrown, meaning the current user doesn't have rights to open the file, that Exception is not handled and the calling function is going to receive it. This is OK. Just because my function doesn't know how to handle an Access Denied problem doesn't mean the code that called me doesn't either. In this case, I simply allow the exception to 'bubble up'.

A sure sign of programming immaturity or inability is the following code

try
{
   OpenFile();
}
catch (Exception ex)
{
   throw new Exception("An error has occurred");
}

Unlike the previous block, this code catches any exception thrown, not just a FileNotFound one. And, unlike the previous code, instead of actually doing something with the exception, this code consumes the actual error then throws a totally unrelated error that's still going to crash the system. However, unlike the first code block, the error that I will get will only say "An error has occurred". It will not tell me what that error was, and to find out I will have to step into the code and debug. Which kills time.

This scenario is unfortunately 80% of the code I am looking at right now. I understand the desire to not let the User Interface show a nasty error, but deep inside the code is not the place to do it in. If you can't handle the exception, let it go. If you must do something with the exception, log it, throw a new one, but attach the old exception so I can see where it failed!!!

It is so obvious the people who wrote this code have not been doing it for any length of time. For all the 'money we save' by hiring foreigners who can't even comment their code because they don't speak English, we waste thousands of man hours trying to 'fix' it.

posted by by Robb Allen @
Comments have been closed on this topic.