Page 1 of 1
About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Fri Jun 13, 2014 10:02 am
by vchhang
Would you explain why option#3 is correct? With the return statement at line 3, wouldn't cause line 7 to become unreachable code? I know the compiler didn't catch it and I am confused as to why.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Fri Jun 13, 2014 11:11 am
by admin
As far as the compiler is concerned, there is a possibility that the return statement at 3 may not get a chance to execute because of an exception thrown by code before //3, in which case, //7 will be reachable. As long as there is a possibility that a line of code will be execute, it cannot be considered unreachable.
HTH,
Paul.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jun 16, 2014 9:10 am
by vchhang
Maybe I am not understanding how "smart" the compiler is. To me, no matter what happens before line 3, line 7 will always be unreachable.
Scenario 1a - There is an exception before line 3. The exception is caught. The return at line 3 gets executed. Line 7 never got executed.
Scenario 1b - There is an exception before line 3, the exception is not caught, execution jumps to the caller. Line 7 never gets executed.
Scenario 2 - There is no exception before line 3. Line 3 executes and returns to the caller. Line 7 never get executed.
What am I missing?
Thank you again.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jun 16, 2014 9:21 am
by admin
You were asking about why option3 is correct.
Now, I am not sure which code are you talking about. Please post exact code.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jun 16, 2014 9:37 am
by vchhang
I am asking why option 3 would be correct.
Code: Select all
public float parseFloat( String s ){
float f = 0.0f; // 1
try{
f = Float.valueOf( s ).floatValue(); // 2
return f ; // 3
}
catch(NumberFormatException nfe){
f = Float.NaN ; // 4
return f; // 5
}
finally {
return f; // 6
}
return f ; // 7
}
If we removing only line 5 and 6, line 7 can never be executed. I'm just curious why this would compile.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jun 16, 2014 9:43 am
by admin
The given catch block catches only NFE. What if a RuntimeException is thrown?
Try catching Throwable and see what happens.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jun 16, 2014 9:49 am
by admin
Btw, I can't make sense of your scenario 1a. why would the return at 3 get executed if there is an exception before it?
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jun 16, 2014 11:15 am
by vchhang
Would line 3 be execution if the exception is caught and handled? I thought line 3 would be executed after finally. It sounds like you are saying, in the even of an exception and it is handled, after finally is executed, the statement after try block is executed. Is this correct?
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jun 16, 2014 7:26 pm
by admin
vchhang wrote:Would line 3 be execution if the exception is caught and handled? I thought line 3 would be executed after finally. It sounds like you are saying, in the even of an exception and it is handled, after finally is executed, the statement after try block is executed. Is this correct?
Code: Select all
try{
stmt 1; <-- If stmt1 throws exception stmt2 will not be executed at all.
stmt 2;
}
catch(...){
..
}
finally{
..
}
You might want to read about exception handling from a good book before attempting questions.
thank you,
Paul.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Fri Jan 08, 2016 1:03 pm
by Simarpreet Singh
Can you please explain the reason for the below two scenarios ?
if i write return statement or throw any exception in finally block, then line 7 is unreachable?
but if i keep finally block empty or write any other statements in it except the return or a statement throwing exception, then it compiles successfully?
Ideally since finally block contains the code that is always executed before the JVM shuts down, so whether finally block is empty or contains any other statement, Line 7 should always be unreachable?
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Fri Jan 08, 2016 5:24 pm
by admin
A method ends when you execute a return statement or throw an exception that is not caught anywhere. So if you write a return statement in finally block, how will the statement after the finally block get executed?
If the finally block is empty, and if no return statement is executed anywhere why do you think the code after it will not be executed?
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Fri Jan 08, 2016 10:45 pm
by Simarpreet Singh
because according to my knowledge finally block is the last that is encountered before the JVM shuts down (that is before the program gets terminated) . So even if finally block is empty or is not having return statement or any exception that is not caught anywhere , it is still encountered at last just before the program is terminated.
Please rectify.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Fri Jan 08, 2016 11:21 pm
by admin
Simarpreet Singh wrote:because according to my knowledge finally block is the last that is encountered before the JVM shuts down (that is before the program gets terminated) . So even if finally block is empty or is not having return statement or any exception that is not caught anywhere , it is still encountered at last just before the program is terminated.
Please rectify.
1. Finally has nothing to do with JVM shutdown or program termination. In fact, if the JVM shuts down in try (say, if you call System.exit() in try, finally will not be executed.
2. A finally block can only be associated with a try block (not with program termination). So if a try block is executed, and if the try block has an associated finally block, then that finally block will always be executed. (except in case of system.exit() as mentioned above).
You should read more about this from a good book or at least read this trail completely:
https://docs.oracle.com/javase/tutorial ... dling.html
or
http://www.javatpoint.com/finally-block ... n-handling
Try running the examples before attempting mock questions.
HTH,
Paul.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Sat Jan 09, 2016 6:06 am
by Simarpreet Singh
Thanks for the clarification.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Tue Jan 19, 2016 3:00 pm
by rianne
public float parseFloat( String s ){
float f = 0.0f; // 1
try{
f = Float.valueOf( s ).floatValue(); // 2
return f ; // 3
}
catch(NumberFormatException nfe){
f = Float.NaN ; // 4
return f; // 5
}
finally {
return f; // 6
}
return f ; // 7
}
Even if you remove 'line // 6', you will still end up with a nice empty finally block! So even if you remove i.e. lines //5 and //6, the code at //7 is still unreachable right? Because you are left with an empty finally block?
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Tue Jan 19, 2016 9:27 pm
by admin
No, if you remove //5 and //6, and if an exception (NumberFormatException or any other) is thrown in the try block, then //7 will be executed. So it is not unreachable.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Wed Jan 20, 2016 6:59 am
by rianne
admin wrote:No, if you remove //5 and //6, and if an exception (NumberFormatException or any other) is thrown in the try block, then //7 will be executed. So it is not unreachable.
If I make it throw a NullpointerException (String s = null; parseFloat(s);), line //7 will never be reached?
But I think it got it worked out now, is it ok to state that:
- The method has to return something
- If the try, catch and finally block return something, //7 is seen as unreachable code by the compiler
- That in fact, as long as the finally block returns something, line //7 remains unreachable code
- And last but not least, that if the try and catch block both return something, and the finally block is empty,
line // 7 is still seen as unreachable because
- the code executes right, and something is returned in the try block
- an exception is thrown in the try block, that is caught in the catch block, which then returns a value
- an exception is thrown that cannot be caught, and line //7 is never reached because the method throws
this exception to it's caller...
- So line 7 only executes if either the try or catch, AND the finally block are empty...
Hope I got it all figured out
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Wed Jan 20, 2016 8:05 am
by admin
rianne wrote:admin wrote:No, if you remove //5 and //6, and if an exception (NumberFormatException or any other) is thrown in the try block, then //7 will be executed. So it is not unreachable.
If I make it throw a NullpointerException (String s = null; parseFloat(s);), line //7 will never be reached?
No, sorry, my bad. Just the NumberFormatException.
But I think it got it worked out now, is it ok to state that:
- The method has to return something
- If the try, catch and finally block return something, //7 is seen as unreachable code by the compiler
- That in fact, as long as the finally block returns something, line //7 remains unreachable code
- And last but not least, that if the try and catch block both return something, and the finally block is empty,
line // 7 is still seen as unreachable because
- the code executes right, and something is returned in the try block
- an exception is thrown in the try block, that is caught in the catch block, which then returns a value
- an exception is thrown that cannot be caught, and line //7 is never reached because the method throws
this exception to it's caller...
- So line 7 only executes if either the try or catch, AND the finally block are empty...
Hope I got it all figured out
You have to look at the possibility of execution of //7. If you are able to find any situation where line //7 will execute, then //7 is reachable. If you don't see any situation where //7 will execute, then it is unreachable.
Now, if you remove 5 and 6, and if code in try throws a NFE, the control will go to catch, which doesn't return anything and then the control will go to finally, which doesn't return either. So the control will go to 7. That means 7 is reachable.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Thu Sep 15, 2016 1:10 am
by Steven1988
Hello,
I want just to mention that a return statement allows to quit the current block.
A block is delimited by an opening and a closing curlibraces.
So, a return statement in the finally block will exit that block and the pregram resumes by executing the subsequent instructions.
I suggest that you check this
java tutorial.
It contains a very good articles that helped me to learn java.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Wed Nov 16, 2016 8:30 am
by mj.anjuthan
Steven1988 wrote:I want just to mention that a return statement allows to quit the current block.
A block is delimited by an opening and a closing curlibraces.
So, a return statement in the finally block will exit that block and the pregram resumes by executing the subsequent instructions.
From what I learnt from several source
when a method executes a return statement, control returns to the code that called the method.
If a document you followed says a return statement allows to quit the current block, then that document may be misleading.
You can experiment with the return statement to understand it better.
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jul 17, 2017 6:21 am
by Javier
Hi Paul!
I have a doubt with this exercise because of the return statement and the finally block. I Know that finally block is always executed wether there is or not thrown exception.
So in this code, I commented the line 7:
public float parseFloat( String s ){
float f = 0.0f; // 1
try{
f = Float.valueOf( s ).floatValue(); // 2
return f ; // 3
}
catch(NumberFormatException nfe){
f = Float.NaN ; // 4
return f; // 5
}
finally {
return f; // 6
}
// return f ; // 7
}
My question is:
If a NFE is thrown, is the return statement of the catch block executed?
Because if the finally block is always executed, how is possible to be executed if the catch block returns the control to the method invoked...
Here I am missing something, I need help
Thank you very much Paul
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Mon Jul 17, 2017 7:55 am
by admin
The return in catch is executed but the method doesn't end (i.e. the return value is not given back to the caller) until finally is finished. However, since finally also has a return statement, the value of this return statement overwrites the value of the previous return statement. Therefore, the caller gets the value returned by the return statement of finally.
Try this code:
Code: Select all
public class TestClass
{
static int x = 5; //0
public static float parseFloat( String s ){
float f = 0.0f; // 1
try{
f = Float.valueOf( s ).floatValue(); // 2
return f ; // 3
}
catch(NumberFormatException nfe){
f = 20.0f ; // 4
return x--; // 5 Observe that x-- will be executed and x will become 4
}
finally {
return 1000.0f; // 6
}
// return f ; // 7
}
public static void main(String[] args){
System.out.println(parseFloat(args[0])); //prints 1000.0
System.out.println(x); // prints 4 This proves that the return statement in
//catch was executed but value returned was from the finally
}
}
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Tue Jul 18, 2017 5:42 am
by Javier
I understand it now!!
Thanks a lot for the explanation!!
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Sun Mar 28, 2021 1:45 am
by baichen7788
why option3 is correct?
If //5 and //6 are removed, there would be a scenario where an exception occurs and the return will never be reached.
option3 is wrong
Re: About Question enthuware.ocajp.i.v7.2.1200 :
Posted: Sun Mar 28, 2021 3:34 am
by admin
Can you show exactly what scenario can occur when? Please post exact code that you have in mind.