Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I am trying to integrate JaCoCo within a JavaCard development environment. However I ran through an issue while trying to cover branches with JavaCard-like exceptions.
In JavaCard, exceptions are not thrown with the regular throw keyord due to memory constraints; Instead throwable classes implements a static method throwIt.
The demo implementation in the JavaCard Development Kit for ISOException is as follows:
public class ISOException extends CardRuntimeException
private static ISOException systemInstance;
public ISOException(short sw)
if (systemInstance == null)
systemInstance = this;
public static void throwIt(short sw)
And it is used as follows:
/* Clean up stuff */
/* .... */
/* Then exit */
When we enter this branch, everything is covered. However, JaCoCo mark this branch as non-covered.
As I understood how JaCoCo works, it puts a probe after the call to throwIt. As it is expected from throwIt not to return, the probe never gets fired and the whole branch is marked as missed.
Is my conclusion correct ? Is there any way to specify if a method is expected to break execution flow (general case) ? These methods are stubbed in unit tests, so maybe the mocking framework could somehow inform JaCoCo that the branch was indeed covered when the stub is executed ?
Thanks in advance.
Marc R. Hoffmann
your understanding is absolutely correct. JaCoCo is designed to to work on JVM level only and does not make any assumptions about langiages or frameworks running on top of the JVM. We currently have no way to specify "extra probes". This would be quite problematic as it has to be configured with the JaCoCo agent and probe positions must be absolutely reproducible, otherwise analysis will fail.
Future versions of JaCoCo might better deal with unexpected exceptions, but up to now we have no idea how this could be implemented without adding significant runtime overhead.
Thanks for the quick answer.
This JavaCard specific way of throwing exceptions only generates an INVOKESTATIC throwIt preceeded by a PUSHI. Do you think I can easily modify the core instrumentation framework so that it considers this method invocation as a throw statement?
This should be possible. Look at the package 'org.jacoco.core.internal.flow'. Probably you need to give the MethodProbesAdapter internal state to remember the last instructions. As soon as encounters the given sequence an additional probe has to be emitted.