## Why is this an issue?

When verifying that code raises a runtime exception, a good practice is to avoid having multiple method calls inside the tested code, to be explicit about which method call is expected to raise the exception.

It increases the clarity of the test, and avoid incorrect testing when another method is actually raising the exception.

### Noncompliant code example

    @Test
    public void testToString() {
      // Do you expect get() or toString() throwing the exception?
      org.junit.Assert.assertThrows(IndexOutOfBoundsException.class, () -> get().toString());
    }

    @Test
    public void testToStringTryCatchIdiom() {
      try {
        // Do you expect get() or toString() throwing the exception?
        get().toString();
        Assert.fail("Expected an IndexOutOfBoundsException to be thrown");
      } catch (IndexOutOfBoundsException e) {
        // Test exception message...
      }
    }

### Compliant solution

    @Test
    public void testToString() {
       Object obj = get();
       Assert.assertThrows(IndexOutOfBoundsException.class, () -> obj.toString());
    }

    @Test
    public void testToStringTryCatchIdiom() {
      Object obj = get();
      try {
        obj.toString();
        Assert.fail("Expected an IndexOutOfBoundsException to be thrown");
      } catch (IndexOutOfBoundsException e) {
        // Test exception message...
      }
    }

## Resources

- JUnit exception testing documentation