Question 1

Java assertions: which statement about the colon (:) detail expression and assert usage is true?

Accepted Answer

Introduction / Context: Java’s assert statement has two forms: assert booleanExpr; and assert booleanExpr : detailExpr;. The colon form supplies a “detail” value that will be included in the AssertionError if the boolean expression evaluates to false. Understanding what is allowed after the colon is key. Given Data / Assumptions: booleanExpr must evaluate to a boolean. detailExpr can be any Java expression; its value is converted to a string (via toString for objects, or string conversion for primitives) when the AssertionError is constructed. Assertions are typically used for internal invariants, not for user-facing error handling. Concept / Approach: The language specification permits any expression after the colon; there is no restriction that it be a String literal. However, best practice is to avoid side effects in either expression, because assertions may be disabled at runtime and side effects would then disappear. Step-by-Step Solution: Check A: Correct. detailExpr may be any expression; its value is attached to the AssertionError.Check B: Asserts are not a replacement for switch default logic; they are intended for debugging invariants, not production control flow.Check C: If detailExpr has no value (e.g., is a statement), the code would not compile; it must be an expression with a value.Check D: Catching AssertionError is discouraged; assertions signal programmer errors and should not be used for recoverable conditions. Verification / Alternative check: Experiment with assert x > 0 : x and assert flag : computeMessage(). Both compile if expressions are valid. Attempting to place a statement (e.g., assignment used purely for side effect) will compile only if it yields a value, but this is bad style. Why Other Options Are Wrong: They either misuse assertion semantics or suggest poor practices. Common Pitfalls: Putting side effects in detail expressions; relying on assertions for normal input validation of public APIs. Final Answer: In an assert statement, the expression after the colon ( : ) can be any Java expression.

Question 2

Java assertion enabling/disabling: which statement about runtime control of assertions is true?

Accepted Answer

Introduction / Context: Java allows fine-grained control of assertion checking at runtime using the -ea/-enableassertions and -da/-disableassertions switches. Understanding their scope and specificity is necessary for configuring development and production behavior. Given Data / Assumptions: Assertions are compiled into bytecode by default in modern Java compilers. By default at runtime, assertions are disabled unless enabled with -ea. VM switches can target packages (with “...” package name patterns) and individual classes. Concept / Approach: The VM applies assertion switches by specificity: per-class directives override per-package directives, which override global. This means you can mix enabling for a package and disabling for a specific class in that package (or vice versa) simultaneously. Step-by-Step Solution: Option A: False. If no flags are passed, assertions remain disabled by default.Option B: “Compiled by default” is broadly true, but this option is ambiguous regarding older source levels; the safer, unambiguously correct statement among the choices is C.Option C: True. Example: java -ea:com.example... -da:com.example.MyClass Main enables for the package but disables for a specific class.Option D: False as stated; it is not “ea wins over da” or vice versa globally—the more specific setting (class over package, package over global) takes precedence. Verification / Alternative check: Run a demo with assertions in com.example.MyClass and in other classes in com.example; combine -ea and -da as shown to observe selective behavior. Why Other Options Are Wrong: A misstates runtime default; D misstates precedence mechanics; B is not the best single correct choice in this set, as the question expects one answer highlighting runtime control. Common Pitfalls: Assuming assertions are enabled in production by default; misunderstanding that specificity, not flag order, controls final behavior. Final Answer: With appropriate VM switches, you can disable assertions for a specific class while enabling them for a package at the same time.

Question 3

Java assertions: pick the three true statements about when to enable, and how selectively to enable, assertion checking.

Accepted Answer

Introduction / Context: This question tests best practices and VM capabilities for assertions. Assertions are intended primarily for development and testing, not for normal production error handling or user input validation. Given Data / Assumptions: (1) “Assertion checking is typically enabled when a program is deployed.” (2) “It is never appropriate to write code to handle failure of an assert statement.” (3) “Assertion checking is typically enabled during program development and testing.” (4) “Assertion checking can be selectively enabled/disabled on a per-package basis, but not per-class.” (5) “Assertion checking can be selectively enabled/disabled on both a per-package basis and a per-class basis.” Concept / Approach: Assertions are primarily for detecting programmer errors and invariant violations in development. The VM supports enabling/disabling at multiple granularities via -ea/-da options, including package and class specificity. Step-by-Step Solution: (1) False: production deployments typically run with assertions disabled for performance and to avoid exposing internal checks to users.(2) True: you should not write recovery code for AssertionError; it indicates a bug. Do not catch it in normal flow.(3) True: enabling during development/testing helps surface latent defects early.(4) False: you can target individual classes as well as packages.(5) True: VM flags allow both per-package and per-class control. Verification / Alternative check: Use -ea:com.example... -da:com.example.Foo to see package enabled, class disabled. This demonstrates both per-package and per-class control. Why Other Options Are Wrong: Options that include statements (1) or (4) are invalid because those statements are false. Common Pitfalls: Treating assertions like user input checks; attempting to catch AssertionError in production code; assuming global on/off only. Final Answer: 2, 3 and 5

Question 4

Java assertions: choose the single true statement about enabling scope and appropriate usage.

Accepted Answer

Introduction / Context: Assertions are a development-time tool. This question differentiates what the VM can control at runtime, and what assertions are good for versus what they are not. Given Data / Assumptions: VM options include -ea and -da with package/class selectors. Assertions throw AssertionError when enabled and the condition is false. Public API argument validation should not rely on assertions (they may be disabled). Concept / Approach: Evaluate each statement strictly against VM behavior and recommended usage. Step-by-Step Solution: A: True. Enable/disable can target specific classes (e.g., -ea:com.example.Foo).B: False. Java does not use “conditional compilation” for assertions; the bytecode remains, and runtime flags control execution.C: False in general for public methods; use explicit checks and throw exceptions. Assertions may be disabled, making them unsuitable for validating public inputs.D: False. If an assertion fails, the runtime throws AssertionError; you do not “choose” an alternate return or exception in the assert statement itself. Verification / Alternative check: Run a small program with -ea:MyClass and observe that only that class’s assertions fire. Why Other Options Are Wrong: They mischaracterize Java’s compilation model or the intended purpose of assertions. Common Pitfalls: Using assertions for user input checking; assuming they are optimized out by the compiler like C’s preprocessor. Final Answer: Assertions can be enabled or disabled on a class-by-class basis.

Question 5

Java assertions practice: select the single true statement about AssertionError and where assertions are suitable.

Accepted Answer

Introduction / Context: Assertions and AssertionError communicate “this code path should be impossible” conditions. While typical usage is via the assert keyword, there are cases where throwing AssertionError explicitly is an appropriate way to mark unreachable code. Given Data / Assumptions: AssertionError is an unchecked error type intended for programming defects. finally clauses execute regardless of whether an exception/error is thrown (barring System.exit, fatal VM errors, etc.). Assertions are more suitable within non-public code (e.g., private methods) to document invariants. Concept / Approach: Evaluate each statement with best practices in mind. Step-by-Step Solution: A: True. Example: inside a switch over all enum constants, in the default branch you can throw new AssertionError("Unhandled value: " + v). This communicates a bug if reached.B: False. Private/internal methods are good places to use assertions for invariants; the statement claims they “should not,” which is incorrect.C: False. finally always runs after try/catch—even when AssertionError occurs—unless the process terminates abruptly for other reasons.D: False. There is no AssertionException; additionally, catching AssertionError for normal control flow is discouraged. Verification / Alternative check: Write a small try/finally that throws new AssertionError(); observe the finally block executes. Why Other Options Are Wrong: They misstate best practices or assert facts contrary to Java’s exception semantics. Common Pitfalls: Using assertions for public API validation; catching AssertionError to continue execution; assuming finally is skipped on errors. Final Answer: It is sometimes good practice to throw an AssertionError explicitly.

Question 6

Assertions in Java: which single guideline is correct and reflects best practice?

Accepted Answer

Introduction / Context: The assert statement is a tool for verifying developer assumptions. Because assertions can be disabled at runtime, code inside assertion expressions should not alter program state in ways the application depends on. Given Data / Assumptions: Assertions may be disabled with JVM flags, causing both the condition and the optional detail expression to be skipped. Public API argument validation should be implemented with explicit checks and exceptions, not assertions. AssertionError indicates a bug, not a recoverable condition. Concept / Approach: Assess each option against widely accepted guidelines: no side effects, not for public preconditions, and no requirement to “handle” AssertionError. Step-by-Step Solution: A: True. If an assertion has side effects, disabling assertions removes those effects, changing program behavior—an anti-pattern. Keep assertions free of side effects.B: False. The main boolean expression must be boolean; the detail expression after the colon can be any expression, but that is not what “assertion expression values can be any primitive type” suggests.C: False. Public preconditions should not rely on assertions because they may be disabled; use exceptions (e.g., IllegalArgumentException).D: False. You normally do not catch AssertionError; it signals a programming error. Verification / Alternative check: Disable assertions with -da and confirm that any side effects placed inside assertions do not occur; this demonstrates why they are dangerous. Why Other Options Are Wrong: They either misstate typing rules or recommend misuses for public contracts and exception handling. Common Pitfalls: Putting logging, counters, or state changes inside assertions; validating user input with assert; catching AssertionError to continue. Final Answer: Assertion expressions should not contain side effects.

Assertions Questions