• Post Reply Bookmark Topic Watch Topic
  • New Topic

Exception Handling Understanding Check  RSS feed

 
Robert Lippens
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just checking my understanding here. I just joined this forum today, graduated back in 2011 with Math and Physics degrees and have spent the last two years trying to find work in my field while being underemployed. About a year ago I decided to switch to software development and now I am in the process of studying for the OCAJ7 exam via the Finegan/Liguori study guide. I am hoping this will at least get me an interview, as right now I can't even get that. (Must have 2+ years of experience for every job I find). Anyway, I just finished the chapter on exception handling and this question threw me for a loop. I think I understand now, but wanted to verify my thought process with those more knowledgeable. Here's the code:



I had thought (at first) the answer was "Dickory Dock" (which wasn't even an option) but turns out it's just Dickory. Here's how I explained it to myself: I knew that Hickory wouldn't get called because the method throws an exception before System.out.println("Hickory") - so we would never see it. Then, since the exception is not handled it propagates up the call stack to method2, which does have a catch statement for the exception and prints out "Dickory". Now, since testMethod2 has handled the exception, testMethod1 will not catch anything, resulting in only "Dickory". Is this also why testMethod1 does not need a "throws ArithmeticException" next to its method name? It throws no errors because we construct it to catch the only error there is? I assume if testMethod3 threw TWO errors, and testMethod2 only caught one, we would need a throws statement in method1. I'll play with it more today.

Thanks guys!

(EDIT: Just did some playing now... the only way I was able to get two exceptions into the code was to put the error into a finally clause in method2. Since method3 threw one exception, the next throw statement was unreachable. Then, since method3 threw an error, if I put the throw statement after testmethod3() call in testmethod2, it was also never seen. This is because testmethod3 produces an exception and so the try block is exited straight into the catch block, skipping my throw statement! Putting it into a finally block ensured it was read and I was finally able to output "Dickory Dock".
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Robert,

Welcome to CodeRanch!

Yes, your understanding about exception propagation is correct.

Just a suggestion - to log the messages (println in your case) AND propagate the exception can be achieved by throwing same (or different) exception from catch block.

Since finally block is always executed (no matter if there is an exception or not), it is not good practice to throw exception from finally block.

I hope this helps.
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Robert Lippens wrote:...it's just Dickory. Here's how I explained it to myself: I knew that Hickory wouldn't get called because the method throws an exception before System.out.println("Hickory") - so we would never see it. Then, since the exception is not handled it propagates up the call stack to method2, which does have a catch statement for the exception and prints out "Dickory". Now, since testMethod2 has handled the exception, testMethod1 will not catch anything, resulting in only "Dickory".


That is correct. If a method handles the exception (and does not re-throw it) then that exception does not bubble up to the caller.

Is this also why testMethod1 does not need a "throws ArithmeticException" next to its method name?


Sort of, yes. testMethod1() doesn't need a throws ArithmeticException declaration because there is no code which requires it. If testMethod1() called testMethod2() but did NOT put it in a try{ } catch (ArithmeticException) { } statement then testMethod1() would need to declare the throws ArithmeticException because testMethod2() could throw one and testMethod1() was not written to handle it. So for example:

Would not work. Even though testMethod2() does not throw the exception, it is declared as possibly throwing it, so testMethod1() must either handle it (with try/catch) or declare that it throws it.

(EDIT: Just did some playing now... the only way I was able to get two exceptions into the code was to put the error into a finally clause in method2. Since method3 threw one exception, the next throw statement was unreachable. Then, since method3 threw an error, if I put the throw statement after testmethod3() call in testmethod2, it was also never seen. This is because testmethod3 produces an exception and so the try block is exited straight into the catch block, skipping my throw statement! Putting it into a finally block ensured it was read and I was finally able to output "Dickory Dock".

You can also re-throw an exception that you catch, after you have processed it. This is somewhat common in code written where the code that generated the exception can't fix it but wants to record the fact that it occured. So you could do something like this:


Welcome to Ranch, and best of luck with your career choices
 
Supun Lakshan Dissanayake
Ranch Hand
Posts: 143
Android Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to Ranch!

Robert Lippens wrote:
Is this also why testMethod1 does not need a "throws ArithmeticException" next to its method name?

ArithmeticException is a Unchecked Exception.
Unchecked exceptions do not need to be declared in a method or constructor's throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary.
(remove try-catch block and throws clause in testMethod2(); it allows you to compile. but runtime error will be occurs as you throw an ArithmeticException in testMethod3())

Robert Lippens wrote:
I assume if testMethod3 threw TWO errors ....

In Java you will ONLY throw Exceptions not ERRORS
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Supun Lakshan Dissanayake wrote:ArithmeticException is a Unchecked Exception.
Unchecked exceptions do not need to be declared in a method or constructor's throws clause if they can be thrown


Good catch, I didn't even look at that.
 
Robert Lippens
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the quick responses and warm welcomes everyone. I have been on the lookout for a programming community to question/help keep up my inspiration in dark times!

I have messed around with my code as suggested and see indeed that A) I don't need to try and catch the unchecked exception (this was just the example the book used, it also states that these are caught at runtime, since they are subclasses of the RuntimeException class) and B) That I can throw the same/different exception in the catch block and that this is best practice when propagating an error. I'm guessing that some methods don't have access to the necessary variables/methods so they can't fix the problem? Also, those println statements are simply logging the error - I take it more complex (and useful) code is placed inside the catch statements to try and resolve the errors normally?

I'll also work on getting the lingo down, before this chapter, I never thought there was a difference between an exception and an error (or that there were checked and unchecked exceptions). From what I have gathered, errors = "Game over man" and exceptions aren't usually as big of a deal. Perhaps another question:

My book states: "Checked exceptions are checked by the compiler and compile time." What exactly does this mean? Does it mean when I javac with the command line, the program won't compile unless the classes I use that throw checked exceptions are dealt with via a throw or try/catch block?

Thanks for all the help again everyone.
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Robert Lippens wrote:My book states: "Checked exceptions are checked by the compiler and compile time." What exactly does this mean? Does it mean when I javac with the command line, the program won't compile unless the classes I use that throw checked exceptions are dealt with via a throw or try/catch block?

Correct.

If methodA throws a checked exception (e.g. MyCheckedException) and if methodB invokes methodA, then methodB must
1) Either surround call to methodA with a try catch block (and catching MyCheckedException)
2) Or declare that it (methodB) throws MyCheckedException

If none of this is done, then program will give a compile time error.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!