Checking exception type hierarchy in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

JUnit Exception Hierarchy: Which exception is caught?

Consider the following JUnit test method. Which exception type will be caught and asserted in this test?

JUnit

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class ExceptionTest {
    @Test
    void testExceptionHierarchy() {
        Exception thrown = assertThrows(Exception.class, () -> {
            throw new IllegalArgumentException("Invalid argument");
        });
        assertEquals(IllegalArgumentException.class, thrown.getClass());
    }
}

A The test will pass because IllegalArgumentException is a subclass of Exception and is caught.

B The test will fail because Exception.class does not catch IllegalArgumentException.

C The test will fail because assertThrows only catches RuntimeException and its subclasses.

D The test will pass but the caught exception type will be Exception, not IllegalArgumentException.

💡 Hint

Remember that IllegalArgumentException extends RuntimeException, which extends Exception.

In JUnit, assertThrows catches exceptions of the specified class or any subclass. Since IllegalArgumentException extends Exception, it is caught and the test passes. The actual exception type is IllegalArgumentException, so the assertion on getClass() succeeds.

❓ assertion

intermediate

Correct Assertion for Exception Subclass in JUnit

You want to assert that a method throws a NullPointerException using JUnit 5. Which assertion correctly verifies the exception type?

A assertThrows(RuntimeException.class, () -> method());

B assertThrows(Throwable.class, () -> method());

C assertThrows(NullPointerException.class, () -> method());

D assertThrows(Exception.class, () -> method());

💡 Hint

Use the most specific exception type to verify the exact exception thrown.

assertThrows expects the exact exception class or subclass you want to verify. Using NullPointerException.class ensures the test only passes if that specific exception is thrown.

🔧 Debug

advanced

Why does this JUnit test fail to catch the exception?

Examine the following JUnit test. Why does it fail even though the method throws an IOException?

JUnit

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class FileTest {
    @Test
    void testIOException() {
        assertThrows(FileNotFoundException.class, () -> {
            throw new IOException("File error");
        });
    }
}

A The test fails because FileNotFoundException is a subclass of IOException, so it should catch IOException.

B The test fails because assertThrows cannot catch checked exceptions.

C The test passes because IOException is a checked exception.

D The test fails because IOException is not a subclass of FileNotFoundException.

💡 Hint

Check the inheritance relationship between IOException and FileNotFoundException.

FileNotFoundException extends IOException, so it is a subclass. But IOException is a superclass and not caught when expecting FileNotFoundException specifically. The thrown exception must be the same or subclass of the asserted exception.

🧠 Conceptual

advanced

Understanding Exception Type Matching in JUnit assertThrows

In JUnit 5, when using assertThrows(ExpectedException.class, executable), which of the following statements is true about the exception matching?

A assertThrows matches exceptions of ExpectedException or any subclass of it.

B assertThrows matches any exception that implements the Throwable interface.

C assertThrows only matches exceptions of the exact class ExpectedException, not subclasses.

D assertThrows matches exceptions only if they are checked exceptions.

💡 Hint

Think about inheritance and polymorphism in Java exceptions.

assertThrows matches exceptions that are instances of the specified class or any subclass. This allows catching more specific exceptions when expecting a general exception type.

❓ framework

expert

JUnit 5 Exception Assertion with Multiple Exception Types

You want to write a JUnit 5 test that passes if either IllegalArgumentException or NullPointerException is thrown by a method. Which approach correctly achieves this?

A Use assertThrowsAnyOf(IllegalArgumentException.class, NullPointerException.class, () -> method()) from JUnit 5.9+.

B Use assertThrows(Throwable.class, () -> method()) and then assert the exception is either IllegalArgumentException or NullPointerException.

C Use assertThrows(IllegalArgumentException.class, () -> method()) and catch NullPointerException separately.

D Use assertThrows(Exception.class, () -> method()) and check the exception type inside the test.

💡 Hint

Check if JUnit 5 has a built-in method to assert multiple exception types.

JUnit 5 does not have assertThrowsAnyOf, but using assertThrows(Throwable.class, ...) to capture the exception and then asserting it is an instance of either expected type (e.g., via instanceof checks or getClass()) is the standard and correct approach.

Practice

1. In JUnit, when you want to check if a method throws an exception of a specific type or any of its subclasses, which assertion method should you use?

easy

A. assertThrows()

B. assertEquals()

C. assertTrue()

D. assertNull()

Solution

1. Step 1: Understand the purpose of assertThrows()

   assertThrows() is designed to check if a block of code throws an exception of a specified type or its subclass.

2. Step 2: Compare with other assertions

   assertEquals() checks equality, assertTrue() checks boolean conditions, and assertNull() checks for null values, none of which check exceptions.

3. Final Answer:

   assertThrows() -> Option A

4. Quick Check:

   Exception type check = assertThrows() [OK]

Hint: Use assertThrows() to check exceptions and their subclasses [OK]

Common Mistakes:

• Using assertEquals() to check exceptions
• Confusing assertTrue() with exception checks
• Expecting assertNull() to verify exceptions

2. Which of the following is the correct syntax to assert that a method throws a NullPointerException in JUnit 5?

easy

A. assertThrows(NullPointerException.class, () -> method());

B. assertThrows(NullPointerException, method());

C. assertThrows(() -> method(), NullPointerException.class);

D. assertThrows(method(), NullPointerException);

Solution

1. Step 1: Recall assertThrows() method signature

   assertThrows() takes the exception class as the first argument and a lambda expression as the second.

2. Step 2: Match the syntax

   assertThrows(NullPointerException.class, () -> method()); correctly uses assertThrows(NullPointerException.class, () -> method()); which matches the required syntax.

3. Final Answer:

   assertThrows(NullPointerException.class, () -> method()); -> Option A

4. Quick Check:

   Correct syntax = assertThrows(NullPointerException.class, () -> method()); [OK]

Hint: Exception class first, then lambda expression in assertThrows() [OK]

Common Mistakes:

• Passing exception instance instead of class
• Swapping argument order in assertThrows()
• Not using lambda expression for the executable

3. Consider the following JUnit 5 test code:

assertThrows(RuntimeException.class, () -> { throw new IllegalArgumentException(); });

What will be the result of this test?

medium

A. Test fails with a compilation error

B. Test fails because IllegalArgumentException is not RuntimeException

C. Test passes because IllegalArgumentException is a subclass of RuntimeException

D. Test passes but warns about unchecked exception

Solution

1. Step 1: Check exception hierarchy

   IllegalArgumentException extends RuntimeException, so it is a subclass.

2. Step 2: Understand assertThrows behavior

   assertThrows(RuntimeException.class, ...) passes if the thrown exception is RuntimeException or any subclass.

3. Final Answer:

   Test passes because IllegalArgumentException is a subclass of RuntimeException -> Option C

4. Quick Check:

   Subclass exception passes assertThrows superclass check [OK]

Hint: assertThrows accepts subclass exceptions of the specified class [OK]

Common Mistakes:

• Thinking exact exception type is required
• Confusing subclass with unrelated exceptions
• Expecting compilation error for subclass exceptions

4. Given this JUnit 5 test:

assertThrows(RuntimeException.class, () -> { throw new FileNotFoundException(); });

The test fails. What is the most likely reason?

medium

A. The lambda expression does not throw any exception

B. The test method does not declare throws IOException

C. FileNotFoundException is a checked exception and must be declared

D. FileNotFoundException is not a subclass of RuntimeException

Solution

1. Step 1: Check exception hierarchy

   FileNotFoundException extends IOException, not RuntimeException.

2. Step 2: Understand assertThrows behavior

   assertThrows(RuntimeException.class, ...) fails because the thrown exception is not RuntimeException or any subclass. Other options are incorrect: checked exceptions like FileNotFoundException do not require declaration in the test method when using Executable lambdas.

3. Final Answer:

   FileNotFoundException is not a subclass of RuntimeException -> Option D

4. Quick Check:

   Non-subclass exception causes assertThrows to fail [OK]

Hint: assertThrows requires the thrown exception to be the specified class or subclass [OK]

Common Mistakes:

• Misidentifying exception subclass relationships
• Ignoring checked exception declaration rules
• Expecting runtime exceptions to behave like checked

5. You want to write a JUnit 5 test that passes if a method throws either an IOException or any of its subclasses, but fails for other exceptions. Which of the following is the best approach?

hard

A. Use assertThrows(Exception.class, () -> method()); and check instance with instanceof IOException

B. Use assertThrows(IOException.class, () -> method());

C. Use try-catch inside test and assert exception type manually

D. Use assertThrows(Throwable.class, () -> method());

Solution

1. Step 1: Understand assertThrows behavior with superclass

   assertThrows(IOException.class, ...) passes if the thrown exception is IOException or any subclass.

2. Step 2: Evaluate other options

   Use assertThrows(Exception.class, () -> method()); and check instance with instanceof IOException requires manual checks and complicates test; Use try-catch inside test and assert exception type manually is verbose; Use assertThrows(Throwable.class, () -> method()); is too broad and accepts all throwables.

3. Final Answer:

   Use assertThrows(IOException.class, () -> method()); -> Option B

4. Quick Check:

   Superclass in assertThrows covers subclasses [OK]

Hint: Use superclass exception in assertThrows to cover subclasses [OK]

Common Mistakes:

• Using too broad exception classes
• Manually checking exception types unnecessarily
• Ignoring assertThrows built-in subclass support