Incorrect coverage on call to method that throws an exception

[vwine]

The following code shows partial branch coverage on the if-block and no coverage on the call to throwIllegalArgumentException. If I put the implementation of throwIllegalArgumentException inline, I get 100% coverage. It's pretty clear that JaCoCo is not marking throwIllegalArgumentException as being visited (and also the if-block) because the thrown exception prevents normal exit of the method (and if-block). Is this a JaCoCo bug? If not, is there a way around this? I'm using the EclEmma plugin for Eclipse, version 2.1.4.

import org.testng.Assert;
import org.testng.annotations.Test;

public class ClassWithThrowMethod
{
public String convertString(String argument)
{
if (!argument.startsWith("Foo"))
{
throwIllegalArgumentException(argument);
}
return argument + "ly";
}

public void throwIllegalArgumentException(String argument)
{
throw new IllegalArgumentException("Illegal argument: " + argument);
}


public class ClassWithThrowMethodTest
{
@Test
public void testConvertString_Foo()
{
Assert.assertEquals(new ClassWithThrowMethod().convertString("Foo"), "Fooly");
}

@Test(expectedExceptions = IllegalArgumentException.class)
public void testConvertString_Bar()
{
new ClassWithThrowMethod().convertString("Bar");
}
}
}

[Marc R. Hoffmann]

Please check the FAQ: http://www.eclemma.org/faq.html#trouble02

Code with exceptions shows no coverage. Why?

The underlying JaCoCo code coverage library works with so called probes.
Probes are inserted into the control flow at certain positions. Code is
considered as executed when a subsequent probe has been executed. In
case of exceptions such a sequence of instructions is aborted somewhere
in the middle and not marked as executed.


Best regards,
-marc

[vwi...@gmail.com]

Thanks Marc! That's what I figured. So, there's no workaround? I mean, there's no way to restructure the code so that it gets better coverage?

[Marc R. Hoffmann]

Hi,

whenever there is an explicit throw statement in your code
JaCoCo/EclEmma will properly consider this as an executed path. The
limitation only applies to implicit exception (thrown within a called
method).

Best regards,
-marc

[vwine]

To work around the issue, but still encapsulate the building of the exception, I do not throw the exception in the method; I just return it. Thanks for your help Marc! Here's the revised code:
import org.testng.Assert;
import org.testng.annotations.Test;

public class ClassWithThrowMethod
{
public String convertString(String argument)
{
if (!argument.startsWith("Foo"))
{

// explicit throw here so JaCoCo/EclEmma will count it as visited
throw getIllegalArgumentException(argument);
}
return argument + "ly";
}

// Changed this to a get method that simply returns the exception, but does not throw it
public IllegalArgumentException getIllegalArgumentException(String argument)
{
return new IllegalArgumentException("Illegal argument: " + argument);