Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

try...catch...finally

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
let's consider two code

code 1:

try {
errorProne();

}
catch(Exception allError) {
toHandle(allError);
}
finally {
mustExecute();
}

code 2:

try {
errorProne();

}
catch(Exception allError) {
toHandle(allError);
}
mustExecute();

are they same? will there be any situation when mustExecute() will not execute in code2?
 
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This sounds like an execise. Why are you asking?
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes.

http://java.sun.com/docs/books/tutorial/essential/exceptions/handling.html
 
Subhajit Mitra
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
it's not a normal code copied from textbook nor i need to submit an assignment. its my own code
in this case "Exception" has been caught which is the base class for all exception so under all normal case catch will be able to catch and there is no need to give finally

i was wondering about special cases like
System.exit(0)
or
Process p = Runtime.getRuntime().exec("<o/s kill command>");

as far as i know if i execute these codes in try in both cases mustExecute() will not execute. but is there any special case where code 1 prevails over code 2
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're missing the most obvious which is what happens if "toHandle" exits abruptly.
 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
this does seem like a homework assignment.
in my limited knowledge, yes they are the same. finally just says to execute this code if an exception is after all exceptions are by passed.
if an exception is caught, all work following it will not occur
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by stephen shields:
this does seem like a homework assignment.
in my limited knowledge, yes they are the same. finally just says to execute this code if an exception is after all exceptions are by passed.
if an exception is caught, all work following it will not occur



Once again, no they are not the same. Under normal circumstances code in a finally block will always execute. If the try block completes normally it will be executed. If the try block throws an exception, it will still execute. If the exception is caught by a catch block, it will still execute. If an exception is caught by a catch block and the catch block throws another exception, it will still execute.

Nothing can cause a finally block to be skipped, however an infinite number of possibilities can cause the JVM to terminate before the finally block can be executed. If a meteor hits the machine, or the power goes off, or the processor blows up, or there's a call to System.exit(), or the application is suddenly terminated, etc. the finally block may not be executed, but there's nothing you can do about that.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If a meteor hits the machine



Man, I hate when that happens.
 
stephen shields
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
lol damn i feel stupid but its ok
posted it while bored
you are right tho. its just that me i never use a finally bc if im designing a gui application, which is in my experience where alot of exceptions are caught, if an exception is caught, i would prefer that a message gets sent to the user.
any code i want to occur when the exception is caught, such as system exit, etc, i make to execute in the catch. now i no i can put it in the finally. but hey we all have our ways. thanks for correcting my mistake tho
 
Ranch Hand
Posts: 429
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stephen, remember that the finally will run even if an exception was caught by a preceeding catch block. You can still handle the exception, and send off a message to the user inside the catch, and then clean up anything you need to in the finally block (close database connections, etc).
 
greenhorn
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ken Blair wrote:

Originally posted by stephen shields:
this does seem like a homework assignment.
in my limited knowledge, yes they are the same. finally just says to execute this code if an exception is after all exceptions are by passed.
if an exception is caught, all work following it will not occur



Once again, no they are not the same. Under normal circumstances code in a finally block will always execute. If the try block completes normally it will be executed. If the try block throws an exception, it will still execute. If the exception is caught by a catch block, it will still execute. If an exception is caught by a catch block and the catch block throws another exception, it will still execute.

Nothing can cause a finally block to be skipped, however an infinite number of possibilities can cause the JVM to terminate before the finally block can be executed. If a meteor hits the machine, or the power goes off, or the processor blows up, or there's a call to System.exit(), or the application is suddenly terminated, etc. the finally block may not be executed, but there's nothing you can do about that.




i dont get it.
System.exit() will terminate the JVM but it's true for both the cases.

so 1st & 2nd code is same.

finally will execute in all cases (except JVM crashes) and in first code, mustExecute() will also execute in all cases.

 
author
Posts: 23912
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, you do know that this is a three year old topic, right? And that maybe many of the participants have moved on?

pooja jain wrote:
i dont get it.
System.exit() will terminate the JVM but it's true for both the cases.



The exit() discussion was a side discussion about finally -- and not really on-topic.

pooja jain wrote:
so 1st & 2nd code is same.



Not true. See next...

pooja jain wrote:
finally will execute in all cases (except JVM crashes) and in first code, mustExecute() will also execute in all cases.



Right, but only the first case has a finally -- so in the second case it is possible for mustExecute() to not execute.

Henry
 
Marshal
Posts: 74654
335
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henry Wong wrote:And that maybe many of the participants have moved on?

We know that one of them, sadly, has died.
 
pooja jain
greenhorn
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i am really sorry to hear that.

actually this thread was referred in one of the recent thread and so i happen to post in it.

@henry
Right, but only the first case has a finally -- so in the second case it is possible for mustExecute() to not execute.


in what circumstances, it's possible for mustExecute() to not execute? that is what my confusion is.

tia.
 
Henry Wong
author
Posts: 23912
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

pooja jain wrote:@henry
Right, but only the first case has a finally -- so in the second case it is possible for mustExecute() to not execute.

in what circumstances, it's possible for mustExecute() to not execute? that is what my confusion is.



1. errorProne() throws an Error.
2. errorProne() throws an exception, which is followed by toHandle() throws an Error.
3. errorProne() throws an exception, which is followed by toHandle() throws a runtime exception.

Henry
 
pooja jain
greenhorn
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henry Wong wrote:

pooja jain wrote:@henry
Right, but only the first case has a finally -- so in the second case it is possible for mustExecute() to not execute.

in what circumstances, it's possible for mustExecute() to not execute? that is what my confusion is.



1. errorProne() throws an Error.
2. errorProne() throws an exception, which is followed by toHandle() throws an Error.
3. errorProne() throws an exception, which is followed by toHandle() throws a runtime exception.

Henry



yes, you are right.
what if i do this:


try {
errorProne();
} catch(Throwable t) {

}
mustExecute();

now point 1 is handelled.
point 2 & 3 also handelled because i am not doing anything in catch block so no exception or error can be thrown.

hope you get it.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic