Checked vs unchecked exceptions: how should a test framework handle exceptions?

Checked exceptions are subclasses of Exception that are not subclasses of RuntimeException; the compiler forces you to either catch them or declare them with throws. Examples: IOException, SQLException, InterruptedException. Unchecked exceptions extend RuntimeException (or are Errors) and need no declaration: NullPointerException, IllegalArgumentException, IllegalStateException. Notably, all Selenium exceptions (NoSuchElementException, TimeoutException, StaleElementReferenceException) are unchecked because they extend WebDriverException, a RuntimeException.

The hierarchy

Throwable
 ├── Error                 (OutOfMemoryError, StackOverflowError: don't catch)
 └── Exception             (checked)
      ├── IOException, SQLException, InterruptedException ...
      └── RuntimeException (unchecked)
           ├── NullPointerException, IllegalArgumentException ...
           └── WebDriverException -> TimeoutException, NoSuchElementException ...

AssertionError (thrown by JUnit and TestNG assertions) is an Error. Some report formats, such as Maven Surefire’s JUnit XML, distinguish failures (assertion errors) from errors (any other exception), which helps triage: a failure usually means the product behaved differently, an error often means the test or environment broke.

Principles for test frameworks

1. Let unexpected exceptions fail the test. The runner reports the stack trace. Catching and logging hides the failure:

// Bad: test passes even when the click failed
try {
    loginPage.submit();
} catch (Exception e) {
    System.out.println("Submit failed");
}

2. Declare or wrap checked exceptions at the right level. Test methods can simply declare throws Exception. In framework utilities, wrap low-level exceptions in a meaningful unchecked one and always keep the cause:

public final class TestDataException extends RuntimeException {
    public TestDataException(String message, Throwable cause) { super(message, cause); }
}

public static String readFixture(String name) {
    try {
        return Files.readString(Path.of("src/test/resources/fixtures", name));
    } catch (IOException e) {
        throw new TestDataException("Could not read fixture " + name, e);
    }
}

Losing the cause (throw new RuntimeException("failed")) destroys the information you need to debug a CI failure.

3. Use try-with-resources for cleanup.

try (Connection conn = DriverManager.getConnection(url, user, pass);
     PreparedStatement ps = conn.prepareStatement("SELECT status FROM orders WHERE id = ?")) {
    ps.setLong(1, orderId);
    try (ResultSet rs = ps.executeQuery()) {
        assertTrue(rs.next(), "order not found");
        assertEquals("PAID", rs.getString("status"));
    }
}

Anything implementing AutoCloseable is closed even if an assertion fails. For WebDriver, quit in an @AfterEach/@AfterMethod rather than relying on the test body.

4. Assert expected exceptions explicitly.

var ex = assertThrows(IllegalArgumentException.class, () -> new Money(-1));
assertEquals("amount must be >= 0", ex.getMessage());

5. Catch narrowly when you do catch. Catching NoSuchElementException to implement “element is absent” logic is acceptable; catching Exception or Throwable broadly is almost never right. Restore the interrupt flag if you catch InterruptedException (Thread.currentThread().interrupt()).

What interviewers look for

• Correct definitions and examples, including that Selenium exceptions are unchecked.
• A firm rule against swallowing exceptions in tests.
• Wrapping with the cause preserved.
• try-with-resources and assertThrows.