Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

doubt on exception part 2 (Java OCA 8 Programmer I Study Guide, Sybex)

 
Ramya Subraamanian
Ranch Hand
Posts: 178
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


In this code above the RuntimeException thrown as throw new RuntimeException("1");in line 10 -> why is this not caught by the catch (RuntimeException e) { in line 11, why is this skipped and finally is called. This is also a question from the OCA programmer guide bye jeanne n scott
 
Les Morgan
Rancher
Posts: 711
17
C++ Java MySQL Database Netbeans IDE Oracle Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From the Java tutorial: "The runtime system invokes the exception handler when the handler is the first one in the call stack whose ExceptionType matches the type of the exception thrown."

This is how I keep it straight in my head: the block for which the tests are being done are defined in the "try" block, once you enter the "catch" block you are no longer in the same structure watching for the exception, but are in the solution stage.
 
Ramya Subraamanian
Ranch Hand
Posts: 178
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
okay so any exceptions that are thrown in the catch or the finally block will never be caught - is my understanding right.
If so then since the exception in the catch block is not caught then the program must terminate right, why must it call the finally block.

abcException in thread "main" ejava.lang.RuntimeException: 3
at Hello3.main(Hello3.java:38)
this is the output i get. this just looks like a stack trace.

shoud i assume that since finally block is always be called ..hence it runs.
 
Les Morgan
Rancher
Posts: 711
17
C++ Java MySQL Database Netbeans IDE Oracle Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
try/catch/finally are constructs that Java uses. The "try" block is where you notify Java that something may happen and to watch for it. The "catch" block is where you tell Java what to catch and how to handle the exceptions generated.

Now the "finally" block is kind of a strange duck, in my opinion: you can avoid it by using a System.exit()--but do you really want to? And you never have to deal with it, unless you actually include it in your structure--it is totally optional to use. So if you include a "finally" block, then it's going to be executed unless you dump out with a System.exit();

So why would you want to if things are so messed up that you need to exit? It's kind of a place to attempt to clean up nicely before continuing on--let's say you have a file open, you may want to flush the buffers and close in your finally block to ensure that you actually have the information you think you wrote. Close down a db connection, maybe do one last gasp and write something to a log file, or, if less critical, it may be someplace you marshal your resources and attempt to see if it is feasible to continue on.

In any case that "finally" block is up to you to include in your program or not. I rarely use them, but when I do I am very glad that there is a block that is going to get executed "no matter what" on the way out.

Ramya Subraamanian wrote:okay so any exceptions that are thrown in the catch or the finally block will never be caught - is my understanding right.
If so then since the exception in the catch block is not caught then the program must terminate right, why must it call the finally block.

abcException in thread "main" ejava.lang.RuntimeException: 3
at Hello3.main(Hello3.java:38)
this is the output i get. this just looks like a stack trace.

shoud i assume that since finally block is always be called ..hence it runs.
 
Ramya Subraamanian
Ranch Hand
Posts: 178
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you Les.my doubts are cleared. I can understand this much better now .
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ramya Subraamanian wrote:In this code above the RuntimeException thrown as throw new RuntimeException("1");in line 10 -> why is this not caught by the catch (RuntimeException e) { in line 11, why is this skipped and finally is called.

Before answering this question, let's properly indent the code snippetNow you clearly can see that the code snippet has 1 try-block with 2 accompanying catch-blocks and 1 finally-block. So when the exception on line1 is thrown, the execution of the code is moved to the first catch-handler matching the thrown exception which is (of course) catch1. So the code in this catch-block is executed and when the exception on line2 is thrown, it's not handled by catch2. And the reason is pretty simple: both catch-blocks are the handlers for the risky code in the try-block. Because line2 is not part of this try-block, the catch-blocks won't be used to handle the exception thrown on line2. As you know, the finally-block (almost) always runs, so when the exception on line2 is thrown, the execution of the code is moved to (the first statement of) the finally-block.

Hope it helps!
Kind regards,
Roel
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ramya Subraamanian wrote:okay so any exceptions that are thrown in the catch or the finally block will never be caught - is my understanding right.

It depends on the code inside the catch and finally blocks! You can have a try-block inside a catch and/or finally block. So we could adjust the code snippet and add a try-block to catch (and handle) both exceptions.If you run this code snippet, you won't see any stack trace anymore. You would get the following output:
a
b
c
caught 1
e
caught 3


Ramya Subraamanian wrote:If so then since the exception in the catch block is not caught then the program must terminate right, why must it call the finally block.

Because a finally-block (almost) always runs! Only in a few (very rare) situations, the finally-block will not run (e.g. calling System.exit(0);). But otherwise the code inside a finally-block is always executed. So in this code snippet the finally-block won't be executedBut you'll probably won't be using that in your code at all (or maybe just once or twice).

Hope it helps!
Kind regards,
Roel
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm creating a separate post about this one, because something weird is happening (and it's easy to overlook). And although Les Morgan's posts are excellent, he didn't notice it as well

Ramya Subraamanian wrote:abcException in thread "main" e java.lang.RuntimeException: 3
at Hello3.main(Hello3.java:38)
this is the output i get. this just looks like a stack trace.

If you look closely to the stack trace (especially the bold text), you'll see the stack trace of the exception thrown in the finally-block. But where's the stack trace of the exception thrown (on line throw new RuntimeException("1");) from the catch-block of IllegalArgumentException? It seems this exception is gone/lost

If you would comment the last line (throw new RuntimeException("3");) of the finally-block, you'll get another output
abce Exception in thread "main" java.lang.RuntimeException: 1
at ab.cd.Hello3.main(Hello3.java:19)

Now you'll get the stack trace from the catch-block of IllegalArgumentException. Why? Because in the original code snippet the finally-block doesn't complete normally. And although it's considered a bad practice (because strange things might happen), it's allowed to return a value or throw an exception from the finally-block. So in the original code snippet the finally-block doesn't complete normally (because of the throw statement), so the uncaught exception thrown (on line throw new RuntimeException("1");) is discarded and forgotten. And that's why you don't see its stack trace when you execute the original code snippet.

In this thread and this one you'll find excellent explanations about which strange behavior you might encounter when the finally-block doesn't complete normally. Both are definitely worth reading!

Ramya Subraamanian wrote:shoud i assume that since finally block is always be called ..hence it runs.

Yes (as explained in one of my previous posts)! A common example when the finally-block is very useful: reading/writing to a file. Before you can read a file, you need to open a file. But once you are done reading, you must close the file. But reading a file is a risky operation and you might encounter an exception. But when this exception occurs, you'll need to close this file as well. And instead of duplicating the code to close the file, you can use a finally-block to close the file. Because a finally-block will always run (when an exception was thrown but also when no exception was thrown). Note: from Java 7 on, you should use the try-with-resource statement and the files will be closed automatically for you (but that's not on the OCA exam, it's on the OCP exam).

Hope it helps!
Kind regards,
Roel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic