Dear Martin, as you already studied our control flow doc <https://www.jacoco.org/jacoco/trunk/doc/flow.html> 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 <https://github.com/jacoco/jacoco/pull/310>. 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 <[email protected]> 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 [email protected] > <mailto:[email protected]>. > To view this discussion visit > https://groups.google.com/d/msgid/jacoco/16b405eb-6e09-4429-943c-dac2c9d72a2en%40googlegroups.com > > <https://groups.google.com/d/msgid/jacoco/16b405eb-6e09-4429-943c-dac2c9d72a2en%40googlegroups.com?utm_medium=email&utm_source=footer>. > <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> -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/jacoco/CE8CCA3B-853C-4FFF-8E7C-01075C420A6B%40mountainminds.com.
