Questions for: Assertions
- Assertion checking is typically enabled when a program is deployed.
- It is never appropriate to write code to handle failure of an assert statement.
- Assertion checking is typically enabled during program development and testing.
- Assertion checking can be selectively enabled or disabled on a per-package basis, but not on a per-class basis.
- Assertion checking can be selectively enabled or disabled on both a per-package basis and a per-class basis.
(1) is wrong. It's just not true.
(2) is correct. You're never supposed to handle an assertion failure.
(3) is correct. Assertions let you test your assumptions during development, but the assertion code—in effect—evaporates when the program is deployed, leaving behind no overhead or debugging code to track down and remove.
(4) is wrong. See the explanation for (5) below.
(5) is correct. Assertion checking can be selectively enabled or disabled on a per-package basis. Note that the package default assertion status determines the assertion status for classes initialized in the future that belong to the named package or any of its "subpackages".
The assertion status can be set for a named top-level class and any nested classes contained therein. This setting takes precedence over the class loader's default assertion status, and over any applicable per-package default. If the named class is not a top-level class, the change of status will have no effect on the actual assertion status of any class.
Option A is correct. Because assertions may be disabled, programs must not assume that the boolean expressions contained in assertions will be evaluated. Thus these expressions should be free of side effects. That is, evaluating such an expression should not affect any state that is visible after the evaluation is complete. Although it is not illegal for a boolean expression contained in an assertion to have a side effect, it is generally inappropriate, as it could cause program behaviour to vary depending on whether assertions are enabled or disabled.
Assertion checking may be disabled for increased performance. Typically, assertion checking is enabled during program development and testing and disabled for deployment.
Option B is wrong. Because you assert that something is "true". True is Boolean. So, an expression must evaluate to Boolean, not int or byte or anything else. Use the same rules for an assertion expression that you would use for a while condition.
Option C is wrong. Usually, enforcing a precondition on a public method is done by condition-checking code that you write yourself, to give you specific exceptions.
Option D is wrong. "You're never supposed to handle an assertion failure"
Not all legal uses of assertions are considered appropriate. As with so much of Java, you can abuse the intended use for assertions, despite the best efforts of Sun's Java engineers to discourage you. For example, you're never supposed to handle an assertion failure. That means don't catch it with a catch clause and attempt to recover. Legally, however, AssertionError is a subclass of Throwable, so it can be caught. But just don't do it! If you're going to try to recover from something, it should be an exception. To discourage you from trying to substitute an assertion for an exception, the AssertionError doesn't provide access to the object that generated it. All you get is the String message.
Discuss About this Question.
public class Test2
{
public static int x;
public static int foo(int y)
{
return y * 2;
}
public static void main(String [] args)
{
int z = 5;
assert z > 0; /* Line 11 */
assert z > 2: foo(z); /* Line 12 */
if ( z < 7 )
assert z > 4; /* Line 14 */
switch (z)
{
case 4: System.out.println("4 ");
case 5: System.out.println("5 ");
default: assert z < 10;
}
if ( z < 10 )
assert z > 4: z++; /* Line 22 */
System.out.println(z);
}
}
Assert statements should not cause side effects. Line 22 changes the value of z if the assert statement is false.
Option A is fine; a second expression in an assert statement is not required.
Option B is fine because it is perfectly acceptable to call a method with the second expression of an assert statement.
Option C is fine because it is proper to call an assert statement conditionally.
Discuss About this Question.
public class Test
{
public static void main(String[] args)
{
int x = 0;
assert (x > 0) : "assertion failed"; /* Line 6 */
System.out.println("finished");
}
}
An assertion Error is thrown as normal giving the output "assertion failed". The word "finished" is not printed (ensure you run with the -ea option)
Assertion failures are generally labeled in the stack trace with the file and line number from which they were thrown, and also in this case with the error's detail message "assertion failed". The detail message is supplied by the assert statement in line 6.
Discuss About this Question.
public class Test
{
public static int y;
public static void foo(int x)
{
System.out.print("foo ");
y = x;
}
public static int bar(int z)
{
System.out.print("bar ");
return y = z;
}
public static void main(String [] args )
{
int t = 0;
assert t > 0 : bar(7);
assert t > 1 : foo(8); /* Line 18 */
System.out.println("done ");
}
}
The foo() method returns void. It is a perfectly acceptable method, but because it returns void it cannot be used in an assert statement, so line 18 will not compile.
Discuss About this Question.
Discuss About this Question.