• Post Reply Bookmark Topic Watch Topic
  • New Topic

Flow Control  RSS feed

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello.

I was taking an online Java practice test I ran into this problem and I still can't understand why the answer is C. I would greatly appreciate it if someone explain to me why the answer is C. Why not A?


Question: What will the output print out?



A. If a is true and b is true then the output is "A && B"
B. If a is true and b is false then the output is "notB"
C. If a is false and b is true then the output is "ELSE"
D. If a is false and b is false then the output is "ELSE".

Answer: Option C

Explanation:

Option C is correct. The output is "ELSE". Only when a is false do the output lines after 11 get some chance of executing.

Option A is wrong. The output is "A". When a is true, irrespective of the value of b, only the line 5 output will be executed. The condition at line 7 will never be evaluated (when a is true it will always be trapped by the line 12 condition) therefore the output will never be "A && B".

Option B is wrong. The output is "A". When a is true, irrespective of the value of b, only the line 5 output will be executed.

Option D is wrong. The output is "notB".

Thanks in advance.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's pretty much all explained there. What part of the explanation do you not understand? What did you expect the output to be and why?
 
Gallen Thomas
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:It's pretty much all explained there. What part of the explanation do you not understand? What did you expect the output to be and why?


Ok, I know now why my answer is incorrect after re-reading their answer and running the code. However, I just don't get their explanation: "when a is true it will always be trapped by the line 12 condition". trapped?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gallen Thomas wrote:I just don't get their explanation: "when a is true it will always be trapped by the line 12 condition". trapped?


I guess they're saying that since it's


only one of those Blocks can be executed, and when a is true, it will always be Block 1 that's executed, thus "trapping" the code path to that Block only, and eliminating the others from consideration (when a is true).

Non-standard wording, I'll grant you.
 
Gallen Thomas
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:
Gallen Thomas wrote:I just don't get their explanation: "when a is true it will always be trapped by the line 12 condition". trapped?


I guess they're saying that since it's


only one of those Blocks can be executed, and when a is true, it will always be Block 1 that's executed, thus "trapping" the code path to that Block only, and eliminating the others from consideration (when a is true).

Non-standard wording, I'll grant you.


Thanks Jeff for the explanation! I don't why I was confused with this question. I guess when I saw "else if(a && b)" I immediately went for that answer. Then I saw option D and didn't pay attention to the output. I should slow down and read the entire problem or get some sleep. :-D

As you might tell, I am practicing to take the OCJP 1.6. Would you have any tips on how to approach these type of questions or any questions for that matter?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gallen Thomas wrote:
Thanks Jeff for the explanation!


Glad to be able to help!

I should slow down and read the entire problem or get some sleep.


Both tactics are advisable in the general case.

As you might tell, I am practicing to take the OCJP 1.6. Would you have any tips on how to approach these type of questions or any questions for that matter?


Um, study and practice Java until you learn it well enough that the cert exam is just a formality?

I'm not really joking there. I'm not a big fan of certifications. Especially ones like the **JP ones that are multiple choice and that are more about testing one's ability to cram for a multiple choice exam than testing one's knowledge of the subject matter. Actually, I should qualify that. I'm not a fan of the cert as an external measure of somebody's Java knowledge. However, if you are using it as a way to find out where your strengths and weaknesses lie, and approach preparation with the goal of "learning Java" rather than the goal of "getting the cert to show I know Java," then it can be a valuable study aid and motivator.

Having said that, allow me to descend from my soap box and say that, while I don't have any particular advice on approaching this kind of exam question, my advice for understanding how a given pice of Java code will behave is, as I already stated, practice, practice, practice. Learn the concept, rather than looking for an approach to the question.

That and, as you already said, slow down, read fully and carefully, and be well-rested.
 
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is confusing what they wrote, particularly since there isn’t a “trap” on line 12. It is also confusing that we indent else‑ifs differently from ordinary ifs. You usually write else‑ifs in some sort of order, like thisBut that question is written out of order. Remember the code in those questions is often written in such a way as to confuse you. They may be inconsistent with their indenting or {} too. This is what you quoted:And this is what you get if all the braces pair up vertically and every keyword has its own pair of braces:-You notice the first else‑if divides into two and has acquired an extra {} pair. It now becomes obvious that the else in line 7 is the other half of the if in line 3, and the if (a && b) is inside that else. Now you should be able to see that you can never reach the if (a && b) block at all. If you ever get into the first else, you can never have a && b evaluating to true, so you must always enter the inner else.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I only found out recently that



is syntactically equivalent to



I always knew they were semantically equivalent, but I guess I had been thinking that else if was an explicit language construct in its own right, when in fact it's just an else without braces whose single body statement is the second if.

That is, it's like we did


where Q just happens to be if (B) { Y }, byt syntactically no different than if we just had a method call or assignment statement there.

Not that I'm going to change how I write my code though. I will continue to write un-braced ifs in that situation while continuing to advise newbies to always use braces. They can discover the exception to the rule on their own.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the best thing to teach newbies is that else ifs should go in order and you indent them as I did with the mark > 80 example from earlier. I would also tell them always to finish with a plain else.
And this thread shows what can happen when you stray from that pattern for else if.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote: else ifs should go in order and you indent them as I did with the mark > 80 example from earlier. I would also tell them always to finish with a plain else.


plusplus

Except that putting the opening brace on its own line is heresy.

Also, for the original code, a decent IDE will warn you that this line:


can never execute.

Of course, it's good for beginners to eschew IDEs and learn to spot that stuff themselves.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not as heretical as putting an opening brace on a line which contains anything else

The one place I would permit {} not on lines by themselves is in array initialisers.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote: . . . Also, for the original code, a decent IDE will warn you that this line: . . ..
Eclipse didn’t.
 
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The thing with copious use of braces with the else is that you get progressively deeper indentation. The if - else if style, while syntactically equivalent to the braces-with-every-else style, helps avoid the arrowhead code anti-pattern and makes code much easier to read, IMO. As for beginners, I don't think it's that complicated -- a few good examples and explanations should clear up the concept.

 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:The thing with copious use of braces with the else is that you get progressively deeper indentation. The if - else if style, while syntactically equivalent to the braces-with-every-else style, helps avoid the arrowhead code anti-pattern and makes code much easier to read, IMO. As for beginners, I don't think it's that complicated -- a few good examples and explanations should clear up the concept.


Agree completely. That's the point I was trying to make, but I guess I didn't do it very well.

The


pattern reads like a switch/case, and visually tracks well to that kind of "selection" logic.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Jeff Verdegan wrote: . . . Also, for the original code, a decent IDE will warn you that this line: . . ..
Eclipse didn’t.


I would think there'd at least be a preference to turn that on or off. Maybe I'm just spoiled by IntelliJ. I pretty much assume that whatever it does, any of the major IDEs will also do.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Braces, braces everywhere, nor any drop to drink.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!