How to test internally caught exceptions

This article takes an in-depth look at how to handle and verify internally caught exceptions in unit tests. When an exception is thrown inside a method but is subsequently caught and handled (e.g. just logged) by a `try-catch` block, the traditional `assertThrows` mechanism cannot be directly verified. The article analyzes the testing challenges brought by this design pattern and provides two main solutions: first, it is recommended to refactor the code to improve testability, such as using `Optional` or a custom result object to clearly indicate the operation results; second, for existing code that cannot be refactored immediately, it explores strategies for indirectly testing exception handling logic by verifying log output or utilizing the `fail()` method.

Understanding the problem: Testing challenges of catching exceptions internally

In software development, we often encounter situations where exceptions are thrown inside methods, but these exceptions are caught and handled by subsequent try-catch blocks. For example, an exception might be logged but not rethrown or otherwise passed up to the upper caller. This design pattern brings challenges to unit testing, because the standard assertThrows assertion mechanism can only detect exceptions thrown from the method under test, but cannot detect exceptions caught inside the method.

Consider the following sample code:

Class A (caller)

 public class A {
    private static Logger logger = LoggerFactory.getLogger("A");
    private B b;

    public A() {
        b = new B();
    }

    public void methodA() {
        b.methodB();
        logger.info("A");
    }
}

Class B (callee, throws and catches exception internally)

 import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class B {
    private static Logger logger = LoggerFactory.getLogger("B");

    public B() {
        //Usually the logger is initialized once in the constructor}

    public void methodB() {
        try {
            // Simulate an internal exception throw new Exception("NULL");
        } catch(Exception e) {
            // The exception is caught and logged, but not rethrown logger.info("Exception thrown internally in B", e);
        }
    }
}

When trying to use assertThrows to test exceptions thrown inside Class B, you run into a problem:

Wrong test example

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

public class ATest { // Assume this is the class that tests A or B @Test
    public void testExceptionInB() {
        B b = new B();
        // Try to assert that b.methodB() throws an exception, but it has been caught internally assertThrows(Exception.class, () -> b.methodB());
    }
}

Executing the above test will result in the following error:

 Expected java.lang.Exception to be thrown, but nothing was thrown.
org.opentest4j.AssertionFailedError: Expected java.lang.Exception to be thrown, but nothing was thrown.

This is precisely because the catch block in methodB has already handled the exception, so that the methodB method itself completes normally without throwing any exception.

Core Issue: Exception Handling Design Flaws

The above design pattern of Class B, which catches and "swallows" exceptions internally without providing any explicit feedback to the caller, is generally considered a bad practice. There are several problems with this design:

1. Poor testability : As shown above, it is difficult to directly verify the occurrence of internal exceptions.
2. Error information is lost : the caller cannot know whether the operation failed and the specific reason for the failure.
3. Difficulty in debugging : When the system behaves abnormally, locating the problem becomes more complicated as error messages are internally digested.
4. Violates the "command-query separation" principle : when a method executes a command, its result should be clear through the return value or exception.

Ideally, exceptions should be caught at a level that can handle them. If a method cannot fully handle an exception, it should rethrow (perhaps encapsulated as a more specific business exception), or explicitly indicate the failure status through a return value.

Recommended solution: Refactor to improve testability

The best way to solve the problem of internally caught exception testing is to refactor your code to follow better exception handling practices, which naturally improves testability.

Option 1: Return Optional or custom result object

If an operation may fail but you don't want to force the caller to handle exceptions (for example, operation failure is not considered an "exceptional" situation, but an expected result), you can use an Optional or a custom result object to explicitly indicate the success or failure of the operation and carry relevant information.

Class B refactoring example (using Optional)

 import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.Optional;

public class BRefactored {
    private static Logger logger = LoggerFactory.getLogger("BRefactored");

    public BRefactored() {
        //Constructor logic}

    /**
     * Perform the operation and return an Optional indicating whether the operation was successful.
     * If the operation fails, Optional is empty and an error is logged.
     * @return If the operation is successful, return a non-empty Optional; otherwise return Optional.empty().
     */
    public Optional<string> methodB() {
        try {
            // Simulate an internal exception throw new Exception("Simulated internal error");
            // Assume this is a successful path and return some data // return Optional.of("Operation successful");
        } catch(Exception e) {
            logger.error("Exception thrown internally in BRefactored: {}", e.getMessage());
            //Explicitly indicate that the operation failed return Optional.empty();
        }
    }
}</string>

Class A corresponding modification example

 import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.Optional;

public class AModified {
    private static Logger logger = LoggerFactory.getLogger("AModified");
    private BRefactored bRefactored;

    public AModified() {
        bRefactored = new BRefactored();
    }

    public void methodA() {
        Optional<string> result = bRefactored.methodB();
        if (result.isPresent()) {
            logger.info("B operation successful: {}", result.get());
        } else {
            logger.warn("B operation failed, handling gracefully in A.");
        }
        logger.info("A");
    }
}</string>

Test example of Class B after refactoring Now, the return value of methodB can be directly tested to determine whether the internal operation succeeded or failed:

 import org.junit.jupiter.api.Test;
import java.util.Optional;
import static org.junit.jupiter.api.Assertions.*;

public class BRefactoredTest {
    @Test
    void testMethodB_failureScenario() {
        BRefactored b = new BRefactored();
        Optional<string> result = b.methodB();
        // Assert that Optional is empty, indicating that the operation failed assertTrue(result.isEmpty(), "methodB should return empty Optional on failure");
    }

    // If there is a successful path, you can test it like this // @Test
    // void testMethodB_successScenario() {
    // BRefactored b = new BRefactored();
    // Optional<string> result = b.methodB();
    // assertTrue(result.isPresent(), "methodB should return non-empty Optional on success");
    // assertEquals("Operation successful", result.get());
    // }
}</string></string>

Option 2: Rethrow specific exceptions

If the inner exception represents an error condition that the caller should be aware of and may need to handle, then the original exception should be caught and re-thrown as an encapsulated, more business-meaning exception.

Class B refactoring example (rethrow business exception)

 import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

// Custom business exception class BusinessOperationException extends RuntimeException {
    public BusinessOperationException(String message, Throwable cause) {
        super(message, cause);
    }
}

public class BRefactoredThrows {
    private static Logger logger = LoggerFactory.getLogger("BRefactoredThrows");

    public BRefactoredThrows() {
        //Constructor logic}

    /**
     * Perform the action. If an error occurs internally, a BusinessOperationException is thrown.
     * @throws BusinessOperationException if the internal operation fails.
     */
    public void methodB() {
        try {
            // Simulate an internal exception throw new IllegalStateException("Critical internal state error");
        } catch(Exception e) {
            logger.error("Exception caught internally, rethrowing as BusinessOperationException: {}", e.getMessage());
            //Catch the original exception, encapsulate and rethrow throw new BusinessOperationException("Failed to perform B operation", e);
        }
    }
}

Test example of Class B after refactoring Now you can use assertThrows to directly test the business exception thrown by methodB:

 import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class BRefactoredThrowsTest {
    @Test
    void testMethodB_throwsBusinessOperationException() {
        BRefactoredThrows b = new BRefactoredThrows();
        // Assert that methodB throws BusinessOperationException
        BusinessOperationException thrown = assertThrows(
            BusinessOperationException.class,
            () -> b.methodB(),
            "methodB should throw BusinessOperationException"
        );
        // Further verify the exception message or reason assertTrue(thrown.getMessage().contains("Failed to perform B operation"));
        assertTrue(thrown.getCause() instanceof IllegalStateException);
    }
}

Alternative: Test existing "bad design" code (not ideal but sometimes necessary)

In some cases, we may not be able to refactor existing code right away, but we still need to write tests for it. For exceptions that are caught and logged internally, the following non-ideal but sometimes practical testing strategy can be adopted.

Solution 1: Verify log output

If an exception is logged after being caught, you can indirectly confirm that the exception occurred by verifying that the expected error message was received by the logging system. This usually requires some additional setup to capture and inspect logs.

Conceptual implementation ideas:

1. Using test log Appender/Listener : Many logging frameworks (such as Logback, Log4j2) allow configuring a special Appender in the test environment, which can capture log events and store them in memory for use by test assertions.
2. Simulate Logger : Use tools such as Mockito to simulate Logger instances. If the Logger is obtained through dependency injection or can be replaced in the test, you can simulate it to verify whether the error() or warn() method is called, and whether the parameters passed in when calling are as expected.

Example (using Mockito to simulate Logger) assumes that Class B can inject Logger through the constructor:

 import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class BInjectableLogger {
    private final Logger logger;

    public BInjectableLogger(Logger logger) {
        this.logger = logger;
    }

    public void methodB() {
        try {
            throw new Exception("NULL");
        } catch(Exception e) {
            logger.info("Exception thrown internally in BInjectableLogger", e);
        }
    }
}

Test example

 import org.junit.jupiter.api.Test;
import org.mockito.ArgumentCaptor;
import org.slf4j.Logger;

import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class BInjectableLoggerTest {
    @Test
    void testMethodB_logsException() {
        //Create a simulated Logger
        Logger mockLogger = mock(Logger.class);
        BInjectableLogger b = new BInjectableLogger(mockLogger);

        b.methodB();

        // Verify whether the logger.info method is called // Capture the parameters passed to the info method ArgumentCaptor<string> messageCaptor = ArgumentCaptor.forClass(String.class);
        ArgumentCaptor<throwable> throwableCaptor = ArgumentCaptor.forClass(Throwable.class);

        // Verify that the info method is called at least once and capture the parameters verify(mockLogger, times(1)).info(messageCaptor.capture(), throwableCaptor.capture());

        // Assert the log message and captured exception type assertTrue(messageCaptor.getValue().contains("Exception thrown internally"));
        assertTrue(throwableCaptor.getValue() instanceof Exception);
        assertTrue(throwableCaptor.getValue().getMessage().contains("NULL"));
    }
}</throwable></string>

Note : If the Logger is obtained statically through LoggerFactory.getLogger(), it will be difficult to simulate directly. You may need tools such as PowerMock, or use the testing tools provided by the logging framework.

Solution 2: Use fail() to ensure that the exception is caught (based on the original answer)

The goal of this approach is to ensure that the exception is actually caught and does not escape higher up the call stack. If the try-catch block of methodB fails to catch the exception (for example, the exception type does not match or the try block logic changes causing the exception to be thrown outside the catch block), then the test will fail.

Test example

 import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.fail; // Import fail

public class ATestOriginalDesign {
    @Test
    void testMethodB_exceptionIsSwallowed() {
        B b = new B(); // Use original Class B
        try {
            b.methodB();
            // If the exception inside methodB is successfully caught and handled,
            // Then the code will be executed here, indicating that the exception has not escaped.
            // At this point, we don't want the test to fail, so fail() is not needed here.
            // This path indicates success if the purpose of the test is to ensure that it *doesn't* throw an exception externally.
            // If the purpose of the test is to ensure that it *internally* throws an exception, this method does not directly verify it.
        } catch (Exception e) {
            // If the catch block inside methodB does not catch the exception,
            //Exceptions will escape here, causing the test to fail.
            fail("Exception was not swallowed by B.methodB(): " e.getMessage());
        }
    }

    // Another scenario that is more in line with the intent of the original answer:
    // If we want to test a method, it *should* catch and handle an exception,
    // But in case it doesn't handle it, we fail the test.
    @Test
    void testMethodB_ensuresNoUnhandledExceptionEscapes() {
        B b = new B(); // original Class B
        try {
            b.methodB();
            // If the code is executed here, it means that methodB successfully handled the internal exception and did not throw it out.
            // For a design that "swallows" exceptions, this is exactly the behavior we expect, so the test passes.
        } catch (Exception e) {
            // If methodB does not catch the exception, the exception will escape here.
            // At this point, we consider this a failure condition since methodB is designed to catch it.
            fail("Expected B.methodB() to swallow its internal exception, but it escaped: " e.getMessage());
        }
    }
}

Limitations of this method : This method is actually testing "the exception did not escape" rather than directly verifying "an exception was thrown internally". For a design like Class B that always catches exceptions, a test like testMethodB_ensuresNoUnhandledExceptionEscapes will always pass , because it just verifies that the catch block of methodB is functioning properly. it cannot directly

The above is the detailed content of How to test internally caught exceptions. For more information, please follow other related articles on the PHP Chinese website!