But what will happen if the code in your try block throws another exception - for example a NullPointerException because a null argument was passed in?But, come to think of it, disaster can strike in other ways: we can run out of memory (OutOfMemoryError), or someone naughty might call Thread.stop() (ThreadDeath)...Of course, every checked exception that you want to propagate out will need its own catch clause that closes the stream and retrows the exception. So, a good day's worth of coding down the line, you might have:Hmmm. Maybe this pattern of handling exceptions is not that good.Oh, that's much better, and a lot less error-prone as well; after all, how many of my junior developers are going to remember to ensure that the stream is closed for RuntimeExceptions and Errors?
 Alright, I take that back. A day that produces code throwing all these exceptions - without wrapping them or anything - is a bad day of churning out exceptionally bad code.
The reason for a finally block is that it delimits a piece of code which is always run. The code in your try block might be run - so long as there is no exception. The code in your catch block might be run, if an exception is thrown. Only the finally block is guarenteed to run. Why is this important? Well, reducing the number of lines of code is an relatively trivial side effect. The real necessity for this is best illustrated by the common example of JDBC Connections. A JDBC connection is a resource which needs opened and closed, and can throw Exceptions. What happens if it throws an Exception while its open? The Connection remains open, though now it is unusable. It only takes a relatively small amount of activity like this for your Database to run out of avaliable connections and your application to grind to a halt. So typically when using a Connection you would always code it in a finally block. Make sense? [ August 02, 2004: Message edited by: Paul Sturrock ]
Its pretty simple. Lets consider the following piece of code:
Now, if I understand you right, your doubt is, when we can just code as in Example 2, why do we need to have a code as in Example 1 by including a finally block. Is that so? Well, if yes, then the answer is pretty simple.
You should always keep in mind that anything that you include in a finally block will ALWAYS be executed no matter what. When I say no matter what, I mean, that block of code will be executed whether or not an exception is thrown. If you code as in Example 2, that is, without any finally block, then in case an IOException is thrown during a call to the read() method, the statement br.close(); will never be executed! In this case, the resource that you have opened up for reading will not be closed and your app will still hold it.
If you include a finally block, however, you will be forcing the resource to be closed even if an exception is thrown.
The output of Example 1 in case an exception is thrown will be:
About to call read() IOException thrown Inside the finally block, about to close file
The output of Example 1 in case of no exception thrown will be:
About to call read() Inside the finally block, about to close file
The output of Example 2 in case an exception is thrown will be:
About to call read() IOException thrown
The output of Example 2 in case of no exception thrown will be:
About to call read() About to close file
So you see, the file will never be closed in the second case (Example 2). So, under such situations where you HAVE to do something critical even if an exception gets thrown, you have to use a finally block.
Now you get it?
Vijayendra <br /> <br />"The harder you train in peace, the lesser you bleed in war"