One of the things I am really annoyed about is the finally block of the famous trio.... try/catch/finally.

Before I get into details, let me explain that I really like the finally block. It has a nice sound to it and of course it does a damn good job, it acts as a placeholder where we can clean up resources. Now if you check out best practices and on exception handling, its strongly recommended that programmers should use the finally block. So here is why I am bit ticked off by the finally block.

I was recently working on a really small application and my customer was my wife. Basically the problem was that the broadband connection that we have at home needs a kick before it can get started... meaning everytime I boot my machine, I first have to renew the IP Address (or it normally takes sometimes up to 10 mins for it to fetch the DNS info etc...) and then open the ISP's web page and login with the provided credentials. Once these steps are done I can then happily surf the internet. Although I might like opening the command prompt and running ipconfig /release and then ipconfig /renew, my wife doesn't share my enthusiasm and is not that computer friendly to repeatedly do these steps. So I wrote a small application which basically runs the ipconfig command using the System.Diagnostics.Process and then uses a HttpWebRequest to POST the credentials to the ISP's web page.

So now that the background story is done... while writing the code I created a separate class for the methods and was had a constructor in the class file. I was basically trying to initialize a few things in there, set some properties etc.... All good so far... but one annoying fact. As everyone already knows, if I initialize an object within one block, with my code looking like this...

try{
        //exception proof code..
        ClassName objname = new ClassName();

}

catch(Exception ex){
        //nice code...
}

finally{
         //clean up stuff
         objname.Dispose();
}

I can't really refer to this object in the finally block... or the compiler will throw the following error message..

Error    1    The name 'objname' does not exist in the current context    <project path>\<file name>.cs    75    17    <Project Name>

I could move my object declaration outside of the block.. and then instantiate the object inside the try block... to something that looks like...

ClassName objname;

try{
          objname = new ClassName();
          ...
          ...

But then the following error will come on build...

Error    1    Use of unassigned local variable 'objname'    <project path>\<file name>.cs    75    17    <Project Name>

Ok.. now what's the purpose of the try/catch/finally block... for exception handling and to clean up resources... so if my object is prone to exceptions while instantiating, where will I catch that? Also, I would really want to dispose of my object and what better place then to do it in finally block? This is the part where I get annoyed everytime. Ideally what I would like to have is that objects declared in the try block should be accessible within the finally block... but of course that's against all the rules...

The solution here would be to do exception handling at all places... so we don't run into any unpleasant issues and of course we can use nested try/catch blocks but that just doesn't agree with my programming aesthetics... Just my 2¢...