Hi Carsten,
one of the main features of JaCoCo is its low overhead and scalability
für *large* projects. To be honest I'm not willing to sacrify this for
this feature. Before we would need some serious testing with large scale
JaCoCo use cases. There are other tools like cubertura which follow a
different startegy and e.g. insert a probe for every source line, which
would give more precise results in the exception cases.
Regarding forks: I'm more than happy to see JaCoCo forks! This is a
great opportunity to test alternative aproaches or major reworks with a
actual user base. Still, if the we see that a major change in JaCoCo
works out well for representative projects we can bring this back to JaCoCo.
Cheers,
-marc
On 23.01.15 20:26, Carsten Otto wrote:
Marc, do you have a comment on this? Especially the "PS" is important
to me right now.
On Tue, Jan 6, 2015 at 3:04 PM, Carsten Otto <[email protected]
<mailto:[email protected]>> wrote:
Hi,
first of all, sorry for the late reply. Holidays got in the way,
and I also finally handed in my PhD thesis.
To your question:
The code change I proposed includes a probe in front of each
INVOKE opcode, which basically is the only change. This way one
can see if the code leading to the INVOKE opcode has been
executed, or not. Currently, this cannot be determined in the case
where an INVOKE opcode throws an exception. Instead, only partial
information (derived from other probes) is used for the computation.
In case I get you correctly, the change you're suggesting goes
along these lines:
BEFORE:
beforeDummy++;
methodInvocation();
afterDummy++
AFTER:
beforeDummy++;
try {
methodInvocation();
} catch (Throwable t) {
throw t; // if this block is reached, we know the invocation
threw an exception
}
afterDummy++;
This way, you can also detect if the method invocation goes
through. However, in addition to the necessary code
instrumentation, you'd need to add more than one probe.
One could also extend the "try" block to cover, for example, the
complete method. However, in thise case there is no way to
determine which of the possibly many opcodes threw an exception.
Maybe I'm not getting you, though. Could you provide a
(pseudocode) example of your idea?
PS: Could you please give me your current gut feeling regarding
the choice of an inclusion or a fork? I've been approached by a
user who was interested in the additional coverage results
reported by my changes, and I strongly believe there is more
interest in the community (this is an invitation to raise your
voice, community!).
Best regards,
Carsten
--
Carsten Otto
[email protected] <mailto:[email protected]>
www.c-otto.de <http://www.c-otto.de>
--
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 on the web visit
https://groups.google.com/d/msgid/jacoco/54C36A60.7060607%40mountainminds.com.
For more options, visit https://groups.google.com/d/optout.
