Page 1 of 1
About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Sat Jul 27, 2013 3:52 pm
by CreepyMulder
Hello !
I got the right answer on this question, but now I'm wondering why :
int i = doIt() / (j = 2);
I thought parenthesis had the highest precedence, so does it mean that "calling a method" has a highest precedence than using parenthesis ?
Thanks :]
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Tue Apr 08, 2014 5:32 pm
by JeramieH
I made the same mistake, I thought the parentheses had the highest priority.
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Wed May 21, 2014 8:43 pm
by admin
As per
JLS 15.7.1:
The left-hand operand of a binary operator appears to be fully evaluated before any part of the right-hand operand is evaluated.
So in doIt() / (j = 2);, the method doIt() will be called first because it is the left operand of /.
HTH,
Paul.
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Sun Aug 17, 2014 4:20 am
by wokingtown11
Can you tell me why the method signature of doIt() has a return type of int?
I got the answer right but not sure of the reasoning behind why a throws statement is an acceptable replacement to a return statement?
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Sun Aug 17, 2014 4:49 am
by admin
Regarding why the return type of the method is int, that depends on the business logic of the method that you are writing. If you have a method that returns a name, you would probably specify the return type as String.
In this case, since it is a code with no real business logic, the return type is int because it is being assigned to an int in the main method.
Throw statement is a valid replacement for a return statement because a method can either complete successfully (in which case it will return a value) or it can fail to do it job and end up with an exception (in which case, it will not be able to return a value). The method can either throw an exception explicitly (as is happening here) or the method may call some other method which throws an exception (for example, if this method tries to open a file). The point is, it is reasonable to expect that a method may fail to perform its job and may end up throwing an exception instead of returning a value. In the given code, we are throwing an exception every single time! So no need for a return value ever.
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Mon Oct 27, 2014 7:34 am
by Daniel Clinton
Trying out some tweaks to this concept
Code: Select all
public class Enthu_2_1260 {
public static void main(String[] args) {
try {
int i = 15 / (0 * doIt());
} catch (RuntimeException re) {
System.out.println(re);
} catch (Exception e) {
System.out.println(e);
}
}
public static int doIt() throws Exception {
throw new Exception("FORGET IT");
}
}
The output is: java.lang.Exception: FORGET IT
The compiler will (try to) return a value of doIt()
regardless of the fact that no return can produce an evaluation of other than zero for the divisor.
I guess the divisor's value must be evaluated before the int division is evaluated?
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Mon Oct 27, 2014 7:49 am
by Daniel Clinton
Answering my own question here but I think I have it now...
The Runtime (Arithmetic) Exception would only get thrown by a disallowed integer division by 0
But the evaluation doesn't get this far.
I think it doesn't even get as far as the evaluation of the multiplication
doIt() must be invoked to return a value to the multiplication,
which in turn must be evaluated to return a value to the division.
And the Exception occurs during the method call
So, think I might have it straight now...?
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Mon Oct 27, 2014 11:43 am
by admin
That is correct!
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Sat Apr 29, 2017 3:02 am
by olaimonas
Hi, I tried to test the following assumption
admin wrote:Throw statement is a valid replacement for a return statement because a method can either complete successfully (in which case it will return a value) or it can fail to do it job and end up with an exception (in which case, it will not be able to return a value). The method can either throw an exception explicitly (as is happening here) or the method may call some other method which throws an exception (for example, if this method tries to open a file).
with this code:
Code: Select all
public class Sample {
public static void main(String[] args) {
}
public static String method() throws Exception {
methodHelper();
}
public static void methodHelper() throws Exception {
throw new Exception();
}
}
However, the compiler gives the following message:
Sample.java:7: error: missing return statement
}
^
1 error
Can the return statement be replaced by another method than throws only certain types of exceptions (for example, while opening a file (would be an IOException I reckon))?
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Sat Apr 29, 2017 3:09 am
by admin
No, a return statement cannot be replaced by another method that always throws an exception because the compiler cannot be sure that a method call will always end up with an exception. It can only check a method code while compiling that particular method but it cannot assume the result of a method call in another method.
HTH,
Paul.
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Tue Nov 28, 2017 5:49 am
by R2-D2-
Hi Paul,
I tried to play around with the code and there's one thing I don't understand. If I have
Code: Select all
public class TestClass {
public static void main(String[] args) {
int j = 1;
int i;
try {
i = doIt() / (j = 2);
System.out.println(i);
} catch (Exception e) {
System.out.println(" j = " + j);
}
}
public static int doIt() throws Exception {
throw new Exception("FORGET IT");
}
}
then the code will compile. (Notice that I have moved the declaration of variable i before the try block and added a println in the try).
However, if I add a
in the catch clause, or right after the catch clause, it will say the variable might not have been initialized. My question is: why does the compiler not complain in the first case?
My guess: in the first case, the compiler knows that i might not be intialized and throw an Exception, but will not complain because the println will not be executed in that case.
Could you please point out if there's a flaw in my reasoning or give a little more info on how this works?
Thanks a lot!
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Tue Nov 28, 2017 8:46 am
by admin
Your reasoning is correct. Complier will complain only if it notices a possible execution path in which a variable will be accessed without prior initialization.
hth,
Paul.
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Fri Dec 08, 2017 5:41 am
by wangchit
I run the code and get the result j=1.
But the answer is "it will not compile". Why?
Re: About Question enthuware.ocajp.i.v7.2.1260 :
Posted: Fri Dec 08, 2017 10:28 pm
by admin
I see that option 1 i.e. It will print j =1 is indeed set as the correct option.
HTH,
Paul.