I have been meaning to write another software development blog post for a little while now, but had struggled to come up with something that is really worth writing about. After browsing StackOverflow and various programming forums and blogs I finally decided that it may be time to visit the “Try Catch Finally” code block. At work recently I have been using it more frequently due to the functionality that I am needing to implement (reading from files/streams, and writing to files/streams).
I’m not going to go into too much detail but just cover two of the areas where I feel plenty of developers either fall short or forget certain concepts about the “Try Catch Finally” block. One of these is hopefully blatantly obvious while the other may not be so clear.
Not a Logic Workflow
Your “Try Catch Finally” block should not be used as a means to control your logical flow of your application. I have read a number of times on StackOverflow where there have been contributions/answers that say something along the lines “Use the ‘Try Catch Finally’ instead of ‘If Else’ to control the flow of your application”. To other contributors credit these contributions/answers get down voted and commented heavily saying that this is wrong, not good practice and is not the reason to be using a “Try Catch Finally” block in the first place.
This thinking is wrong (using a “Try Catch Finally” for logical workflow), in that the “If Else” block is a means of controlling the logical flow of your application and the “Try Catch Finally” block is a means of handling thrown exceptions from your application. I always try to check for nulls, the correct format and instances of objects before using them (where ever possible), but I also always encase my methods with an appropriate “Try Catch Finally” block. Not only is this good programming practice but it helps ensure that your application is bullet proof, everything is logged and nothing unexpected happens.
For example if I am reading or writing to a file/stream there is always a chance that an IO exception will be thrown. By encasing my logic in the “Try Catch Finally” block I can correctly handle this exception, log it and then in the “finally” part close the file or stream if it is still open after the exception.
Remember this if you are to take something away from this post:
- “If Else” statements control your logical flow of your application.
- “Try Catch Finally” statements handle your exceptions thrown by your application.
Execution of Finally
This got me at first when I was learning about the “Try Catch Finally” code block. In nearly all circumstances the “finally” component will always get called, even if there is no exception thrown in your “try” component and you are returning. Originally I did not believe this but when I tried it out for myself, I was so surprised; I was not lied to by my lecturer, the textbook and the website I was referring to. If all three sources all said the same thing then I probably should have believed them I guess 😛
Here is an example where you may think that the “finally” component will not get called.
public String getStringValue(String value) {
...
try {
if ("None".equals(value)) {
return "Nothing";
} else {
return "Found at least one.";
}
} catch (Exception e) {
logger.error(e.message());
// Do more stuff.
} finally {
Console.WriteLine("I was still called.");
// Do more stuff.
}
...
}
Why might you think that the “finally” component is not called? Well in the “try” component there is a return statement. If the method in the “try” does not throw an exception then we should drop out of this “getStringValue(int value)” method. However, as we have a “finally” statement, before we drop out of this method we will always write to the console “I was still called.”, and do any other stuff that is not shown in this code snippet.
To all the developers out there, if you use add a “finally” component in your “Try Catch” statement then be aware that it will always be called.
Christopher Tom Kochovski 