The pages of this web site are not formatted to conserve paper, but my new book (ISBN: 0-9745862-0-X) is formatted to save paper, save your printer cartridge, save a loose-leaf binder, and save money. If you prefer to work my exams from printed pages, then give your printer a rest and buy my new book.
Today, you can find my book at amazon.com.
| No. | Answer | Remark | |
|---|---|---|---|
| 1 | a e | -ea -enableassertions | Two command-line switches used to enable assertions in non-system classes are -ea and -enableassertions. |
| 2 | a e | -da -disableassertions | Two command-line switches used to disable assertions are -da and -disableassertions. Remember that all of the letters are lower case. |
| 3 | a | -disableassertions | Two command-line switches used to disable assertions in non-system classes are -da and -disableassertions. Remember that all of the letters are lower case. |
| 4 | c g | -esa -enablesystemassertions | Two command-line switches used to enable assertions in system classes are -esa and -enablesystemassertions. Remember that all of the letters are lower case. |
| 5 | a b d e f | By default assertions are disabled at run-time. Assertions can be selectively enabled for any named class. Assertions can be selectively enabled for any named package. If assertions are selectively enabled for any named package then assertions are automatically enabled for the subpackages. Assertions can be selectively enable for the unnamed package in the current working directory. | |
| 6 | c | AssertionError | An AssertionError is thrown to indicate that an assertion has failed. Don't be fooled by the name AssertionException. |
| 7 | b e | With assertions enabled it prints 210210 followed by an AssertionError message. With assertions disabled it prints 210210-1 | If, under normal operating circumstances, the default label of a switch statement should not be reached, then an assert statement can be placed after the default label to verify that an unexpected condition has not not occurred. |
| 8 | b e g | With assertions enabled it prints 012. With assertions disabled it attempts to print an infinite sequence of numbers. As a rule, the boolean expression of an assert statement should not be used to perform actions that are required for normal operation of the program. | An assert statement should not be used as demonstrated in the program. The boolean expression of the do-loop depends on the value of the local variable i1. The value of i1 is set within the boolean expression of the assert statement. If assertions are disabled, then the boolean expression of the assert statement is not processed and the value of i1 is not updated with each iteration of the loop; so the loop runs indefinitely. |
| 9 | a d | Assertions should not be used to validate arguments passed to public methods. Assertions should not be used to perform processing that is required for the normal operation of the application. | Assertions may be enabled or disabled at run time. Since assertions are not always enabled, they should not be used to validate the parameters of public methods. Parameter checking is typically published in the API specification of a method and must be enforced even when assertions are not enabled. Rather than use an assertion, an appropriate runtime exception should be thrown such as IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException. However, an assertion may be used to validate the parameters of a nonpublic method. Since assertions are not always enabled, an assertion should not be used to perform operations that are required for the normal operation of the program. For example, the boolean expression of an assertion should not be used to produce the side effect of incrementing a variable that controls a loop statement. If assertions are disabled then the loop is unlikely to function as intended. Section 14.20 of the Java Language Specification defines "unreachable" statements. If an assert statement is "unreachable" as defined by the JLS, then a compile-time error is generated. In contrast, a programmer may believe that some points in the code will not be reached as a result of design assumptions. For example, a programmer may believe that the default case of a switch statement will never be reached. An assertion can be placed in the default case to verify the behavior of the switch statement. |
| 10 | b c | The compiler will generate an error if an assert statement is "unreachable" as defined by the Java Language Specification. A catch clause should not be used to catch an AssertionError. | Section 14.20 of the Java Language Specification defines "unreachable" statements. If an assert statement is "unreachable" as defined by the JLS, then a compile-time error is generated. In contrast, a programmer may believe that some points in the code will not be reached as a result of design assumptions. For example, a programmer may believe that the default case of a switch statement will never be reached. An assertion can be placed in the default case to verify the behavior of the switch statement. While the exception handling mechanisms of Java have been designed to allow for recovery from Exceptions, the assertion mechanisms have been designed to discourage recovery attempts. An assertion is used to verify that the program has not strayed beyond the bounds of expected behavior. For example, suppose that you go to bed one night, and your pet dog is sleeping on the floor next to your bed. Before going to sleep, you make the assertion that your dog will still be there in the morning. When you wake up, you find that a different dog is sleeping in place of your pet. How do you recover from the failure of your assertion? Since you probably did not expect your dog to be mysteriously replaced during the night, it is unlikely that you have already developed an effective recovery routine. However, if you had planned for a dog swapping exception, then the recovery should be handled by the exception handling mechanism rather than the assertion mechanism. |
| 11 | a b d | With assertions enabled it prints ABC followed by an AssertionError message. With assertions disabled it prints ABC followed by an AssertionError message. In this code example an assert statement could not be used in place of the "throw" statement. | If the default label of a switch statement should not be reached under normal operating circumstances, then the default label might be a good location for an assert statement. If a method is declared with a non-void return type and if no return statement appears after the switch statement, then each case of the switch must have a return statement or a throw statement. The throw statement is used rather than an assert, because the compiler knows that the assert statement is not functional when assertions are disabled. |
| 12 | a d | With assertions enabled it prints ABC followed by an AssertionError message. With assertions disabled it prints ABCE | If the default label of a switch statement should not be reached under normal operating circumstances, then the default label might be a good candidate for the use of an assert statement. |
| 13 | d e | In this code example a throw statement must be used in place of the assert statement. Compile-time error | If the default label of a switch statement should not be reached under normal operating circumstances, then the default case becomes a good candidate for the use of an assert statement. If a method is declared with a non-void return type and if no return statement appears after the switch statement, then each case of the switch must have a return statement or a throw statement. The throw statement is used rather than an assert, because the compiler knows that the assert statement is not functional when assertions are disabled. |
| 14 | a d f | With assertions enabled it prints an AssertionError message. With assertions disabled it prints nothing. The assert statement is being used to check a control-flow invariant to verify that the control flow never reaches a point in the program. | The assert statement indicates that the programmer believes that b1 and b2 will never be true simultaneously, and the assert statement should not be reached under normal operating conditions. |
| 15 | a d f h | If assertions are enabled at run time it prints an error message. With assertions disabled it prints 1112. The assert statements are being used to check a precondition--something that must be true when the method is invoked. Method m2 is an example of an improper use of an assert statement: an assert statement should not be used for argument checking in a public method. | Assertions may be enabled or disabled at run time. Since assertions are not always enabled, they should not be used to validate the parameters of public methods. Parameter checking is typically published in the API specification of a method and must be enforced even when assertions are not enabled. Rather than use an assertion, an appropriate runtime exception should be thrown such as IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException. However, an assertion may be used to validate the parameters of a nonpublic method. |
| 16 | b c e | If assertions are not enabled at run time it prints nothing. With assertions enabled it prints an error message. The assert statement is being used to check a postcondition--something that must be true when the method completes successfully. | Variable c equals 200 when the assertion is checked. |
| 17 | b d e | If assertions are not enabled at run time it prints nothing. With assertions enabled it prints nothing. The assert statement is being used to check a class invariant--something that must be true about each instance of the class. | This question is an example of using assertions to check a class invariant--something that must be true about each instance of the class. Although a class invariant must be true before and after the execution of each public method, the invariant is typically only checked at the end of each method and constructor. |
| 18 | a d f h | With assertions enabled it prints an error message. With assertions disabled it prints: true,true,false The combination of the if/else statements and the assert statement indicate that the programmer expects no more than one boolean, b1, b2 or b3, to be true. The assert statement is being used to check an internal invariant--something that the programmer assumes to be true at a particular point in the program. | Method m1 has a series of if/else statements. The first if statement is processed if none of the booleans are true. The second is processed if only b1 is true. The third is processed if only b2 is true. A set of three booleans can exist is eight states. The three if statements account for three of those states; so five more states remain. The assert statement indicates that the programmer assumes that only one of those five remaining states is valid--that is the state where only b3 is true. The combination of the three if statements and the assert statement indicate that the programmer believes that no more than one of the booleans will be true at that point in the program. That assumption is called an internal invariant. |
| 19 | a c e | Prints "Only b1 is true" followed by an error message. The combination of the if/else statements and the assert statement indicate that the programmer expects no more than one boolean, b1, b2, or b3, to be true. The assert statement is being used to check a control-flow invariant to verify that the control flow never reaches a point in the program. | Method m1 has a series of if/else statements. The first if statement is processed if none of the booleans are true. The second is processed if only b1 is true. The third is processed if only b2 is true. The fourth is processed if only b3 is true. A set of three booleans can exist in one of eight states. The first four if statements account for four of those states; so four more states remain. The combination of the three if statements and the fact that an AssertionError is thrown from the last else block indicates that the programmer believes that no more than one of the booleans will be true when method m1 is being processed. An assumption concerning the state of a set of variables is called an internal invariant. In this case, however, the assertion was tested by verifying that control never reached a particular point in the program. Based on the testing technique, we would say that the assertion tests a control-flow invariant. A throw statement is used in place of an assert statement, because the throw statement can not be disabled. As a result, the method is certain to generate an error once control passes beyond all of the return statements. The declared return type of method m1 is String. No return statement appears after the sequence of if statements; therefore, every if statement must either return a String or throw an exception. Assertions can be disabled at run time, so an assert statement in the final if block is no guarantee that an exception will be thrown. For that reason, an assert can not replace the throw statement. |
| 20 | b e f | The flow of control does not reach a particular point in the program. The default case of a switch statement is not reached. The else block of an if/else statement is not reached. | A control-flow invariant is placed at a point in the program that the programmer assumes will never be reached. Two examples are the default case of a switch statement or the else block of an if/else statement. It makes no sense to use an assert statement to verify that the flow of control does reach a particular point in the program, because it is unlikely that an assertion error is helpful when the program is found to be functioning correctly. An assert statement placed at the beginning of a method is generally used to check a precondition. An assert statement that is placed at the end of a method to check the state of some variables is generally said to be checking a post condition. However, it is also possible that an assert statement placed at the end of a method might also be checking a control-flow invariant. The correct term depends on the usage. |