• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is finally, really finally

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I have the following code block -
public class ExceptionTest {
public static void main(String[] args) {
try {
ExceptionTest test = new ExceptionTest();
test.foo();
} catch (MyException ex) {
System.out.println("An Error!!");
//ex.printStackTrace();
}
}
public void foo()
throws MyException {
int j = 0;
try {
j = 5 / 0; // will give an error since you cannot divide by zero
} catch (Exception e) {
throw new MyException();
} finally {
System.out.println("Shucks");
}
}
}
class MyException
extends Exception {
public MyException() {
System.out.println("MyException() Constructor Invoked");
}
}
I am getting an output of
MyException() Constructor Invoked
Shucks
An Error!!
According to the exception handlign mechanish, if there is a finally block, then, execution continues after the exception is caught into the finally block. Then, how is it showing the message in the exception block of the calling method? Also, is it safe to have clean-up code in the finally block of individual methods?
TIA,
Manoj.
 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Manoj,
finally{} will define the last actions in the method foo() when an exception is caught in your try/catch/finally block. It is not the last thing that the application will do.
foo() just returns to main() where you could have coded another finally{} block.
[This message has been edited by Colin Kenworthy (edited October 22, 2001).]
 
Ranch Hand
Posts: 1514
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Execution continues after the finally block if the exception is handled/caught. You did not catch the exception, you re-threw it in your catch block. Hence, you are delegating handling the exception to the calling method.

Bosun
 
Manoj Pooleery
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Thanks to the replies. But still, I have these doubts - on the occurrence of an exception, I want the calling method to handle it, at the same time, I want some cleanup to be done. Relating this to the flow of control, when I throw the exception up to the calling method, will the control be transferred to the callee (before or) after the finally block is executed? Also, is it a good design consideration to have the cleanup code in a finally block in the child method?
Second doubt relating to Exceptions - regarding the throwing of the Exceptions, what is the difference between throwing a new exception with Exception.getmessage() and the exception itself? Does it affect the stack trace in any way?
TIA,
Manoj.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The finally clause is exactly the right place to do cleanup in the called method. Just beware that sometimes, the cleanup code can throw exceptions as well; if an exception has already been thrown, you don't want any cleanup exceptions to obscure it. For exampleIn this example, exceptions are caught and re-thrown. You won't find any of this back in the stack trace: it will give the location where the exception was first thrown. If you don't want this, call Throwable.fillInStackTrace() or throw a brand new Exception (bad practice in most cases, unless the new exception handles nested exceptions - see the source for java.rmi.RemoteException for an example of proper nested exception handling).
- Peter
 
reply
    Bookmark Topic Watch Topic
  • New Topic