Visualizing exceptions

[Martin Paljak]

Hello,

I'm using JaCoCo as the visual aid for a fault-injection framework, that assists developers in a niche Java ecosystem of JavaCard, to verify some countermeasures on code level within a desktop JVM, by deterministically or fuzzily introducing branch flips and data corruption while running a testsuite.

It works by instrumenting the bytecode to reach places normal execution would not allow to go.

One aspect of it is actual testing (works well), the other is giving a visual aid "what exactly got covered", and for that I'm using JaCoCo.

So far, so good. But I'd like to improve how exceptions are handled. As they are used all over the JavaCard code to signal back status from a smart card, it is a bit sad that by default JaCoCo shows actually reached code as "red", when the indication that would assist me in this case would be "green".

In the control flow doc, there is the note "The current JaCoCo implementation ignores edges caused by implicit exceptions and the method entry. This means we consider SEQUENCE, JUMP, EXIT.". 

OK. Let me show three different outcomes:

- "throw new" gets tagged as green, fine.

- how exceptions (static instances with variable value inside) is 99.9% thrown in JavaCard - red.

- And another one.

Is there a rationale why it is like this, and if/how should I proceed to mark such lines as green?

Best,

Martin

[Marc Hoffmann]

Dear Martin,

as you already studied our control flow doc you know that we analyze the control flow only by inserting a minimal number of probes at “strategic” positions. From the probes we can interfere the preceding instructions and branches. Unfortunately this does not work for exceptions where basically at every instruction the control flow has a potential edge to the exception handler or method exit (with an exception). So far we did not come up with a practical solution for this. What could be considered:

• Adding a probe after every bytecode instruction would create a massive overhead and would render JaCoCo useless for most projects
• Installing generic exception handlers and somehow analyzing the exceptions come with huge complexity that will come with the risk to change the code’s behavior.

What we did some time ago is to add a probe before every line which contains a method call. So at least the preceding line is shown as covered. This improved the situation a bit for common cases with limited overhead.

Any practical idea how to fix this limitation is welcome!

Cheers,

-marc

On 17. Nov 2025, at 09:47, Martin Paljak <martin...@gmail.com> wrote:

Hello,

I'm using JaCoCo as the visual aid for a fault-injection framework, that assists developers in a niche Java ecosystem of JavaCard, to verify some countermeasures on code level within a desktop JVM, by deterministically or fuzzily introducing branch flips and data corruption while running a testsuite.

It works by instrumenting the bytecode to reach places normal execution would not allow to go.

One aspect of it is actual testing (works well), the other is giving a visual aid "what exactly got covered", and for that I'm using JaCoCo.

So far, so good. But I'd like to improve how exceptions are handled. As they are used all over the JavaCard code to signal back status from a smart card, it is a bit sad that by default JaCoCo shows actually reached code as "red", when the indication that would assist me in this case would be "green".

In the control flow doc, there is the note "The current JaCoCo implementation ignores edges caused by implicit exceptions and the method entry. This means we consider SEQUENCE, JUMP, EXIT.". 

OK. Let me show three different outcomes:

- "throw new" gets tagged as green, fine.

<Screenshot 2025-11-17 at 10.17.43.png>

- how exceptions (static instances with variable value inside) is 99.9% thrown in JavaCard - red.

<Screenshot 2025-11-17 at 10.16.58.png>

- And another one.
<Screenshot 2025-11-17 at 10.15.47.png>

Is there a rationale why it is like this, and if/how should I proceed to mark such lines as green?

Best,

Martin

--
You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jacoco/16b405eb-6e09-4429-943c-dac2c9d72a2en%40googlegroups.com.
<Screenshot 2025-11-17 at 10.17.43.png><Screenshot 2025-11-17 at 10.16.58.png><Screenshot 2025-11-17 at 10.15.47.png>

[Martin Paljak]

Hi Marc,

On Monday, 17 November 2025 at 20:18:30 UTC+2 Marc R. Hoffmann wrote:

Dear Martin,

as you already studied our control flow doc you know that we analyze the control flow only by inserting a minimal number of probes at “strategic” positions. From the probes we can interfere the preceding instructions and branches. Unfortunately this does not work for exceptions where basically at every instruction the control flow has a potential edge to the exception handler or method exit (with an exception). So far we did not come up with a practical solution for this. What could be considered:

• Adding a probe after every bytecode instruction would create a massive overhead and would render JaCoCo useless for most projects

This feels excessive at first sight, indeed.

• Installing generic exception handlers and somehow analyzing the exceptions come with huge complexity that will come with the risk to change the code’s behavior.

Agreed, I'm already not happy how my hacks for branch flipping + JaCoCo-s additions explode the number of branches seen per line. And getting a robust solution feels complicated.

What we did some time ago is to add a probe before every line which contains a method call. So at least the preceding line is shown as covered. This improved the situation a bit for common cases with limited overhead.

10+ years seems like a longstanding issue. No newer ideas?

Any practical idea how to fix this limitation is welcome!

Not sure, I don't know the internals of JaCoCo that well (yet). My intuition wants to guide me towards a naive solution where "I want ISOException.throwIt() line to show green" so hypothetically adding a probe to every method _entry_ (incl the .throwIt() could be the direction, and mark the caller line as visited.

Then again, I deliberately currently omit the overhanging "API" from both instrumentation as well as JaCoCo analysis, and that would break that assumption (JavaCard API-s are loaded by the parent classloader, whereas the code I'm interested in is isolated into a separate loader).

Maybe adding an option "fullcover" (default off, of course) or similar to get maximum results at the cost of times/space resources would still make sense?

It would definitely work for my use case, as most JavaCard apps are not even in near the "who needs more than 640K" limit.

Best,

Martin

[Marc Hoffmann]

Hi Martin,

some random remarks:

10+ years seems like a longstanding issue. No newer ideas?

Maybe let’s put that in perspective: When we added this JaCoCo was already 6 years old. The JVM spec (byte code) has also not really changed since that time (except for the addition of invokedynamic and condy which we already sopport and use).

adding a probe to every method _entry_ (incl the .throwIt() could be the direction, and mark the caller line as visited.

Note that JaCoCo works on bytecode. With very few exceptions JaCoCo does not think in “lines” but in bytecode instructions. Line coloring is just an artifact of using the debug information in the class files to assign instructions to source line. Currently the coverage model is binary: A instruction is executed in a way that the following instruction is also executed or not. The model has no state for “we tried to execute it but something happened”.

Also while method execution is the most common case, almost any other bytecode instruction can throw an exception think of cast for example.

Maybe adding an option "fullcover" (default off, of course) or similar to get maximum results

As JaCoCo already is quite complex by supporting a wide range of Java versions and source languages maintenance is already beyond our capacity. Therefore we decided not to introduce (and maintain!) feature toggles which adds more another dimension to complexity.

Please feel free to experiment with the code base and suggest solutions!

Cheers,

-marc

To view this discussion visit https://groups.google.com/d/msgid/jacoco/3a61ca79-4b9f-4ac7-b504-d18c4de021cbn%40googlegroups.com.