== Why is this an issue?

When verifying that code raises an exception, a good practice is to avoid having multiple method calls inside the tested code, to be explicit about what is exactly tested.


When two of the methods can raise the same *checked* exception, not respecting this good practice is a bug, since it is not possible to know what is really tested.


You should make sure that only one method can raise the expected checked exception in the tested code.


=== Noncompliant code example

[source,java]
----
@Test
public void testG() {
  // Do you expect g() or f() throwing the exception?
  assertThrows(IOException.class, () -> g(f(1)) ); // Noncompliant
}

@Test
public void testGTryCatchIdiom() {
  try { // Noncompliant
    g(f(1)); 
    Assert.fail("Expected an IOException to be thrown");
  } catch (IOException e) {
    // Test exception message...
  }
}

int f(int x) throws IOException {
  // ...
}

int g(int x) throws IOException {
  // ...
}
----


=== Compliant solution

[source,java]
----
@Test
public void testG() {
  int y = f(1);
  // It is explicit that we expect an exception from g() and not f()
  assertThrows(IOException.class, () -> g(y) );
}

@Test
public void testGTryCatchIdiom() {
  int y = f(1);
  try {
    g(y); 
    Assert.fail("Expected an IOException to be thrown");
  } catch (IOException e) {
    // Test exception message...
  }
}
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

include::../message.adoc[]

include::../highlighting.adoc[]

'''
== Comments And Links
(visible only on this page)

include::../comments-and-links.adoc[]
endif::env-github,rspecator-view[]