C# Exceptions and Finally
/
I’m writing a new version of the C# Yellow Book and I’ve been going through the chapters to make sure they still make sense. Today I’ve been playing with Exceptions. These are things that programs do when really bad things happen. When things are going badly for me in a chess game I have this annoying habit of kicking the board over and storming of to do something else. Exceptions are just like that, but for programs.
If a program finds itself in a situation where it really can’t go any further it can throw an exception and make the issue somebody else’s problem. Really bad in this case means things like “I asked for a number and you’ve given me some text” or “You asked for a file and I can’t find it”. This means that a proper programmer will put such potentially moody code into a try – catch construction so that they can deal with any tantrums that might be thrown:
try
{
// Potentially moody code
}
catch
{
// Code to recover the situation
}
If anything in the block under the try throws an exception the program runs the code in the catch block to try and put things right. When I was younger and more desperate to be liked I used to make sure that code I wrote didn’t ever throw exceptions, but tried to sort things out and carry on. Ask my object to load something from a file that doesn’t exist and it would return a null reference and keep going. Sure, the program that went on to use that null reference would explode some time afterwards, but at least my method hadn’t thrown a tantrum.
Now I’m more nasty. I let my programs throw exceptions if they are asked to do stupid things. That way the fault is generated much closer to the real reason why it happened. Problem is, that sometimes I don’t want to just pass an exception on, I want to do a bit of tidying up myself before I blow away the person that calls me. I can do this by catching the exception in my method and then throwing a new one.
try
{
// Potentially moody code
// Code to tidy things up
}
catch
{
// Code to tidy things up
throw new Exception ("Bad news message to caller");
}
Of course the problem here is that I have to write the code to tidy things up in more than one place. Once if everything works, and again if the exception is thrown. Which is where finally comes in:
try
{
// Potentially moody code
}
catch
{
throw new Exception ("Bad news message to caller");
}
finally
{
// Code to tidy things up
}
You don’t have to add a finally part to your try – catch construction, but if you do it is where you should put all your tidy up code. This is the code that must run whether or not the exception is thrown, and irrespective of what happens in the blocks above. I use code in the finally part to do things like close files, release objects and say bye-bye to network connections. And it works well except in one situation, which is kind of why I’m writing this blog post.
The code in my finally clause will not run if there is nothing to catch any exceptions thrown by the code in my try – catch construction. In other words, if the exception my code throws will cause the program to end for lack of an exception handler the finally clause will not run. I did some experiments to prove this, and decided it was something worth noting.
The thinking, I suppose, is that if the program is going to stop anyway, what is the point of allowing it to run any more code. Most of the time the finally clause will be releasing resources that will be freed anyway when the program is terminated. However, it is not always as simple as that. Sometimes finally code might want to say a formal goodbye to a remote host, or log some information.
Since you can’t rely on someone to always catch exceptions that you might throw (particularly if they are stupid enough to make bad calls of your methods in the first place) I think that this means you need to be a bit careful about using finally. If this means putting tidy up code into a method and then calling it both in the try and catch parts of your program, this might be a step worth taking.
