Assertions - Pointing out the errors Questions and Answers

Q: Which line is an inappropriate use of an assertion? public class Sample25 { public static void main(String[] args) { int i = 0; while (i < 3) { assert i++ < 3; } System.out.println(i); } }

The loop's only increment lives inside the assertion, so without -ea nothing advances i and the while loop never ends. With assertions enabled it terminates and prints 3; disabled, the program hangs. A loop variable must never be advanced inside an assert.

Q: Which line is an inappropriate use of an assertion? public class Sample26 { static { assert load() : "load failed"; } static boolean load() { return false; } public static void main(String[] args) { System.out.println("started"); } }

Initialisation work must not depend on an assertion. With -ea the failing assertion escapes static initialisation as ExceptionInInitializerError and main never runs; without it load() is never called at all. Either way the class's readiness is decided by a debugging flag.

Q: Which line is an inappropriate use of an assertion? public class Sample27 { public boolean equals(Object o) { assert o != null; return o instanceof Sample27; } }

The equals contract requires that x.equals(null) return false rather than fail, so a null argument is expected input and not a broken invariant. With -ea this assertion turns a contract-conforming call into an AssertionError. The instanceof test already handles null correctly by returning false.

Q: Which line is an inappropriate use of an assertion? public class Sample28 { public static void main(String[] args) { java.io.File f = new java.io.File("data.txt"); assert f.exists() : "data.txt missing"; System.out.println(f.length()); } }

Whether a file is present is a condition of the environment, not an invariant the code controls, and it can change between the check and the use. Disabled, the assertion is skipped and length() silently returns 0 for a missing file. Absent input is handled with a real test and an exception.

Q: Which line rests on a mistaken assumption? import java.util.*; public class Sample29 { public static void main(String[] args) { Set<String> s = new HashSet<String>(); s.add("b"); s.add("a"); assert s.iterator().next().equals("a"); System.out.println(s); } }

A HashSet gives no ordering guarantee, so asserting which element comes first encodes an accident of the current implementation. It may hold today and stop holding on another JDK or after a resize. Ordering is asserted only on a type that promises it, such as TreeSet or LinkedHashSet.

Q: Which line rests on a mistaken assumption? public class Sample30 { public static void main(String[] args) { long start = System.currentTimeMillis(); work(); assert System.currentTimeMillis() - start < 100 : "too slow"; System.out.println("done"); } static void work() { } }

Elapsed time depends on the machine, its load and garbage collection, none of which the code controls, so this assertion can fail on correct behaviour. Assertions state facts that must be true by construction; performance belongs in a benchmark, not in an assert.

21.

Which line is an inappropriate use of an assertion?

public class Sample21
{
    public Sample21(String name)
    {
        assert name != null : "name required";
        this.name = name;
    }

    private final String name;
}

A.assert name != null : "name required";
B.this.name = name;
C.private final String name;
D.Nothing here is inappropriate.

Answer: A

The constructor is public, so rejecting a null name is part of the contract callers rely on and has to hold with assertions disabled. As written, a null slips through in production and surfaces much later as a NullPointerException far from its cause. A public constructor validates with an explicit throw.

Discuss in Forum

22.

Which line is an inappropriate use of an assertion?

public class Sample22
{
    public static void main(String[] args)
    {
        String home = System.getProperty("app.home");
        assert home != null : "app.home not set";
        System.out.println(home.trim());
    }
}

A.No line here misuses an assertion.
B.assert home != null : "app.home not set";
C.String home = System.getProperty("app.home");
D.System.out.println(home.trim());

Answer: B

A system property is external configuration, not an internal invariant, so its absence is a real runtime condition the program must handle whether or not -ea was passed. Disabled, the check is skipped and the next line throws NullPointerException with no explanation of the cause.

Discuss in Forum

23.

Which line contains the error?

public class Sample23
{
    public static void main(String[] args)
    {
        int size = 5;
        assert size > 0;
        assert size > 0;
        System.out.println(size);
    }
}

A.The print, because size is reported after being asserted
B.The main method, because it cannot contain assertions
C.Neither assertion is wrong, but the second is redundant and should be removed.
D.The declaration, because the variable is not final

Answer: C

Both assertions compile and both pass, so the program is correct; nothing between them changes size. Repeating an identical check adds no information and misleads a reader into hunting for the difference. Assertions are documentation as much as verification, and duplicated ones read as an editing mistake.

Discuss in Forum

24.

Which line contains the error?

public class Sample24
{
    static int parse(String s)
    {
        assert s != null;
        return Integer.parseInt(s);
    }

    public static void main(String[] args)
    {
        System.out.println(parse(null));
    }
}

A.assert s != null; fails to compile
B.parse(null) cannot pass null to an int parameter
C.Nothing is wrong; the program prints 0.
D.The assertion is skipped without -ea, so Integer.parseInt(null) throws instead

Answer: D

parse is not public, so asserting the precondition is reasonable. The fault is the caller: main knowingly passes null, which is a bug the assertion only reports when -ea is set. Without it Integer.parseInt(null) throws NumberFormatException, which names the symptom rather than the cause.

Discuss in Forum

25.

Which line is an inappropriate use of an assertion?

public class Sample25
{
    public static void main(String[] args)
    {
        int i = 0;
        while (i < 3)
        {
            assert i++ < 3;
        }
        System.out.println(i);
    }
}

A.assert i++ < 3;
B.while (i < 3)
C.System.out.println(i);
D.Nothing here is wrong.

Answer: A

The loop's only increment lives inside the assertion, so without -ea nothing advances i and the while loop never ends. With assertions enabled it terminates and prints 3; disabled, the program hangs. A loop variable must never be advanced inside an assert.

Discuss in Forum

26.

Which line is an inappropriate use of an assertion?

public class Sample26
{
    static
    {
        assert load() : "load failed";
    }

    static boolean load() { return false; }

    public static void main(String[] args)
    {
        System.out.println("started");
    }
}

A.No line here is in error.
B.assert load() : "load failed";
C.static boolean load() { return false; }
D.System.out.println("started");

Answer: B

Initialisation work must not depend on an assertion. With -ea the failing assertion escapes static initialisation as ExceptionInInitializerError and main never runs; without it load() is never called at all. Either way the class's readiness is decided by a debugging flag.

Discuss in Forum

27.

Which line is an inappropriate use of an assertion?

public class Sample27
{
    public boolean equals(Object o)
    {
        assert o != null;
        return o instanceof Sample27;
    }
}

A.public boolean equals(Object o)
B.Every line above is correct as written.
C.assert o != null;
D.return o instanceof Sample27;

Answer: C

The equals contract requires that x.equals(null) return false rather than fail, so a null argument is expected input and not a broken invariant. With -ea this assertion turns a contract-conforming call into an AssertionError. The instanceof test already handles null correctly by returning false.

Discuss in Forum

28.

Which line is an inappropriate use of an assertion?

public class Sample28
{
    public static void main(String[] args)
    {
        java.io.File f = new java.io.File("data.txt");
        assert f.exists() : "data.txt missing";
        System.out.println(f.length());
    }
}

A.java.io.File f = new java.io.File("data.txt");
B.System.out.println(f.length());
C.The code is correct as it stands.
D.assert f.exists() : "data.txt missing";

Answer: D

Whether a file is present is a condition of the environment, not an invariant the code controls, and it can change between the check and the use. Disabled, the assertion is skipped and length() silently returns 0 for a missing file. Absent input is handled with a real test and an exception.

Discuss in Forum

29.

Which line rests on a mistaken assumption?

import java.util.*;

public class Sample29
{
    public static void main(String[] args)
    {
        Set<String> s = new HashSet<String>();
        s.add("b"); s.add("a");
        assert s.iterator().next().equals("a");
        System.out.println(s);
    }
}

A.assert s.iterator().next().equals("a");
B.s.add("b"); s.add("a");
C.System.out.println(s);
D.Nothing here is wrong.

Answer: A

A HashSet gives no ordering guarantee, so asserting which element comes first encodes an accident of the current implementation. It may hold today and stop holding on another JDK or after a resize. Ordering is asserted only on a type that promises it, such as TreeSet or LinkedHashSet.

Discuss in Forum

30.

Which line rests on a mistaken assumption?

public class Sample30
{
    public static void main(String[] args)
    {
        long start = System.currentTimeMillis();
        work();
        assert System.currentTimeMillis() - start < 100 : "too slow";
        System.out.println("done");
    }

    static void work() { }
}

A.No line here is in error.
B.assert System.currentTimeMillis() - start < 100 : "too slow";
C.long start = System.currentTimeMillis();
D.System.out.println("done");

Answer: B

Elapsed time depends on the machine, its load and garbage collection, none of which the code controls, so this assertion can fail on correct behaviour. Assertions state facts that must be true by construction; performance belongs in a benchmark, not in an assert.

Discuss in Forum

Loading…

Topics

Subject Categories

Tags: Assertions - Pointing out the errors Questions and Answers || Assertions - Pointing out the errors MCQ Questions and Answers || Assertions - Pointing out the errors GK Questions and Answers || Assertions - Pointing out the errors GK MCQ Questions || Assertions - Pointing out the errors Multiple Choice Questions and Answers || Assertions - Pointing out the errors GK || GK on Assertions - Pointing out the errors || Java Programming Questions and Answers || Java Programming MCQ Questions and Answers || Java Programming GK Questions and Answers || GK on Java Programming

Assertions - Pointing out the errors Questions and Answers

Topics

Subject Categories

About Us

Stay informed about all important Dates & Notifications