Given the NineOneOne class
public class NineOneOne {
static boolean emergency;
public static void most important(String[] args) {
if (!emergency());
say1(); // line n1
if (emergency());
else if(emergency())
say2();
}
static boolean emergency() {
return emergency ^= true;
}
static void say1() {
System.out.print(“say1 “);
}
static void say2() {
System.out.print(“say2 “);
}
}
What’s the end result in the event you attempt to compile and run the code? Select one.
A. There’s a compilation error because of unreachable code at line n1.
B. Compilation succeeds and there’s no output.
C. say1
D. say2
E. say1 say2
Reply. This query addresses a number of features. The first one is probably consideration to element, which in fact generally is a significantly essential ability in debugging code that you just didn’t write. Extra features embody boolean operations, unwanted effects, and the if/else building.
The “consideration to element” facet of this query is reasonably excessive, and it’s not frequent to seek out this degree of trickiness in examination questions. Did you discover the semicolons on the finish of each traces that begin with if? One other matter of element, albeit associated to the primary, is that the indentation is inappropriate (and it’s not our intention to show you right into a Python fan!). Nonetheless, from a syntactic perspective, the code is legitimate. Moreover, there is no such thing as a unreachable code. This tells you that possibility A is inaccurate; the code will compile.
As a aspect notice, unreachable code is often not thought of to be a compilation error in conditions the place whole blocks of code subordinate to an if or a case are unreachable. These particular instances are supposed to allow the equal of conditional compilation and might be helpful in conditions reminiscent of debugging and testing as a result of they permit whole chunks of code to be enabled, disabled, or swapped out. Due to this fact, the next doesn’t elicit any grievance from the compiler:
if (false) {
System.out.println(“Debugging”);
// extra code
}
Against this, swapping the if for some time, as within the following code, is rejected by the compiler as unreachable:
whereas (false) { // error: unreachable assertion
System.out.println(“Debugging”);
// extra code
}
Transferring to the opposite choices: It’s best to analyze the Boolean variable known as emergency. The variable shouldn’t be initialized explicitly, nevertheless it’s an occasion discipline, so it’s reliably initialized to false in the course of the object’s allocation section.
Discover that the emergency() methodology inverts the worth of the emergency discipline every time it’s known as. That is carried out by the unique OR (XOR) project operator (^=), and the code returns the ensuing worth every time it’s known as.
Now that what’s happening with the emergency discipline and methodology, have a look at the physique of the code that calls that methodology. The primary two if checks do nothing conditional, as a result of they finish in semicolons. Nonetheless, they serve to invert (to true) after which reinvert (again to false) the worth of the emergency variable.
The indentation of the code is deceptive, however when you’ve noticed the semicolons on the finish of these first two if statements, you’ll acknowledge that the tactic say1() will probably be invoked it doesn’t matter what worth the emergency() methodology returns.
On the second if assertion, the worth returned from the emergency() methodology is fake, so management goes to the else department and the third if—and with it, the third name to emergency(). That third name returns true, which invokes the say2() methodology.
As a result of each the say1() and say2() strategies are invoked, say1 say2 is printed to the console. This implies possibility E is appropriate and choices A, B, C, and D are incorrect.
Conclusion. The right reply is possibility E.
Supply: oracle.com
