Dzone promoted a link called "One of the Most Powerful Debugging Practices," showing the use of a trap. The example is in C#, but a Java version is offered. Interesting thought - worth it?
The idea is that you use a trap() method (or a trap(boolean)) in your code, and when it gets hit, you know you've hit an execution path. (Presumably you remove the traps once they're not necessary.) The trap() itself has a debug mode, so if the application is in production mode, the trap does nothing.
It's an assert, almost. The main difference is that it would be closer to an "assert true" than an assert itself, and that resumption of the code is easier with the trap.
The thought that you need something like this to validate that you've hit all your execution paths is strange to me, because I try to rely on test-driven development in the first place. I try to not write code if coverage isn't part of a test, on my best days. I violate that a lot more than I like to admit. So a trap() would help me, I guess, to make sure I'm running all my code if my cobertura tripwire isn't hit.
But I'd probably never use it personally. The idea bothers me, that my production code just has this extra execution path in it , even shortcircuited so that the JIT will get rid of it soon enough.
How about you?