• Post Reply Bookmark Topic Watch Topic
  • New Topic

what is the emphasis on the finally block?  RSS feed

 
Suresh Ramanan
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi!

i am really sorry.
though there have been threads on this topic in the past, i have not been able to draw a conclusion as to what the significance of the finally block really is.
Please explain.
--------------------------------------------------------------------------
scenario 1:

try{
//open a db connection
//something can go wrong here
}catch(Exception e){
//handle the exception and print stack trace
}finally{
//close the db connection
}

scenario 2:

try{
//open a db connection
//something can go wrong here
}catch(Exception e){
//handle the exception and print stack trace
}

//no finally block here.. this is the calling method code
//close the db connection

------------------------------------------------------------------------------------
Please validate my understanding.

1) After the finally executes (whether or not an exception occurs), the program does not terminate. The control goes back to the calling method. Am i right?
2) If control goes back to the calling method, nevertheless, then what is the need for a finally block? Is it just good design, that improves modularity and maintainability? Or is it a failsafe mechanism for something else that i am missing to understand?
3) Is System.exit() programmatical? In that case, my try block does not have it. But i still would like to know what happens if it does? Will the two scenarios be any different? Will finally save the day for the scenario 1?

Thank you so much.

Suresh
 
K. Tsang
Bartender
Posts: 3648
16
Firefox Browser Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For your 3rd question, if you have System.exit() inside the try block then the finally block will not run. For Q1 and Q2 the question is the usefulness of the finally block.

If exceptions occur in the finally block, those exceptions are ignored by the JVM. But programmatically you will need the try/catch block inside for say closing database connection. The primary purpose is if there is a finally block, the code inside will definitely run (with or without exceptions).

For your 2 scenarios, the 2nd one is practically the same as putting the db closing inside the try block. But if there is exception then the db will not be closed. However, putting closing in finally block, no matter what happens it will close the connection.

Hope this helps.
 
Lee Kian Giap
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For your 2 scenarios, the 2nd one is practically the same as putting the db closing inside the try block. But if there is exception then the db will not be closed.


Are you sure ?

It is totally different !!! ... if exception thrown inside try block and handle in catch block , the db is still closing.
the db is not closing unless exception is rethrow from catch block, or an exception throw from finally block.

please be careful.
 
Lee Kian Giap
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suresh Ramanan,

If you want to understand from design , finally block is for resource cleaning (which is not related to memory or garbage collection) or undo some operation.
 
Suresh Ramanan
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all!

thanks a lot!
but i still am a little hazy!

i understand that finally is mainly used for cleaning up resources.

but how different is scenario 2 from scenario 1?
Scenario 1 does a clean job. fine... what about scenario 2?

when no exception is thrown, will both work the same?
if an exception is thrown, will scenario 2 close the db or not?

Thanks,
Suresh
 
Lee Kian Giap
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
okay, for what you have provided, it "seems" no different

Why I say "seems" ?

It comes to the point that your scenario 2 is opening a chance for bad thing to happened in future when code changed, either changed by other developer or changed by you but you forgot/unknown about this problem.

Why I say there will have some bad thing to happen in future?

In the future, when you are doing exception handling in your daily work, mostly you will only catch Checked Exception. When one using a catch block to handle exception, one shouldn't just simply print the stack trace, this is not handling exception, this is lazy/unknown way of a developer doing things. Why, if your statement causes an Checked Exception, and you just print a stacktrace, the remaining code after the try/catch/finally block will continue, if those operations are business logic as a whole, you will causes a situation of inconsistency. So, if you are not going to handle it , you should let it throws from the current method to the calling method in the stack (means using the keyword throws declare on the method, so you don't need to do a catch block, but you might still have a try/finally without catch to release resource).


---------------------------------------------------------------
Before I continue, here is the simple rules/specification
---------------------------------------------------------------
When a checked exception thrown from a statement (rules is "throws or handle")
"throws" means declare throws AbcdefException in your method declaration to let it throw back to the calling method.
"handle" means using catch block inside the method where the statement causes exception thrown.
---------------------------------------------------------------


Abovementioned that you need to let it throws back to the next method in stack. Following the rules, if you let it throws back to the calling method, the calling method again must "throws or handle" ...
Now if you can handle it here (what I mean is not just print stacktrace, cuz this is not handle), this calling method does not need the "throws" declaration, that's fine.
BUT, if you still can't handle it and you need to continue throwing through more calling method on the stack ( let say another 5 calling method) , can you see it , all the 5 calling methods declaration need to have the keywords "throws", is it a mess ?? SURE, especially when you are using the design concept of coding to interface, your method interface are highly couple to different Exception. ( this is very important in some situation which cost you a lot , such as when changing from JDBC to iBATIS to Hibernate ... those exception is tightly coupled)
How to solve this problem? the answer is , use chaining exception.
Means,




So, now can you see that it is important to have your code inside the finally block ??

Got it ? no ? nvm , I put the Scenario 2 here

scenario 2:



So, in this situation, your db connection not close .... Wow , system will die when put into production and live ~

GOT IT ???

All the best !
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please UseCodeTags when posting code or configuration. Unformatted code and configuration is very difficult to read. You can edit your post to include them by using the button.
 
Suresh Ramanan
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@ Lee Kian Giap
wow that was a really thorough explanation. Thanks for all your efforts.
I get it now.

Best wishes,
Suresh
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!