Filtering: Finally block coverage

[mchr3k]

Consider the following simple block of Java code:

try
{
  System.out.println("A");
}
catch (RuntimeException ex)
{
  System.out.println("B");
}
finally
{
  if (f())
  {
    System.out.println("finally");
  }
}

In bytecode this is transformed into the following:

try
{
  System.out.println("A");
  if (f())
  {
    System.out.println("finally");
  }
}
catch (RuntimeException ex)
{
  System.out.println("B");
  if (f())
  {
    System.out.println("finally");
  }
}
catch (Throwable th)
{
  if (f())
  {
    System.out.println("finally");
  }
  throw th;
}

The duplicates of the finally block code are all tagged with the original line numbers. This means the reported coverage of the finally block is not as expected. For example consider the conditional line:

if (f())

In the original source code it looks like there are only two branches to cover. However the coverage report claims that there are six branches to cover. This is because there are three duplications of the conditional line.

I think JaCoCo should handle finally blocks specially to track coverage of these blocks in a way that is less confusing.

[marchof]

This is another topic for filtering, see wiki.

[mchr3k]

The current filtering wiki page doesn't actually talk about how best to handle this code duplication caused by the implementation of finally blocks.

On the one hand there really are more paths than you would expect but on the other I'm not convinced that should actually be exposed to a user of JaCoCo.

What do you think? Should JaCoCo be combining the coverage of the duplicated finally block in a different way?

[marchof]

Yes, in this particular case from the developers point of view the expectation would be that the execution data from the normal and the exceptional path is combined. That's in another interesting use case filtering..

[mchr3k]

I would love to get any thoughts you might have on how to implement this kind of filter. I'm not sure whether to modify the insertion of probes or to try and reconcile coverage of the existing probes at the analysis stage.

I think it will be tricky to reliably spot the blocks of duplicated byte code without having any false positives.

[marchof]

I know this is tricky and might result in false positives.

In any case I see this as a analysis only feature (like all filtering) and should not affect instrumentation and probe insertion.

[marchof]

Merge this with our filtering story #15, added this scenario to wiki page.