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?

First off, thank you for the article (I wrote the Trap article).

Second, I think the biggest advantages of the Trap is not the code coverage, it is that it makes it very easy to single step through all the code the first time each part runs. There's a lot of times that makes me realize something that other testing would not find as well. Sometimes it even makes me re-think the approach I am using.

thanks - dave

I heard David Thielen's "writing bug free code" presentation during the late 80s.  The party line then was make massive use of assert statements and instrument the allocator (malloc/free or your suballocator).  I practiced that repeatedly and it was a big help in the system software that I was building.  Glad to see that David is still sharing his debugging techniques!

Scott - thank you very much.

How is this better than putting trace log statements in all over the place or using something like AOP to do so?

This seems like a really manual way to junk up code with useless noise.

Hi James;

There are two advantages to this approach:

1. It drops you in the debugger to single step through each part of your code the frist time you test it. I have found this to be a major help.

2. You remove these when you hit them when you're on them in the debugger. Using something like logging requires that you go back and find the matching statement from the log output which takes a lot longer.

thanks - dave

Using something like logging requires that you go back and find the matching statement from the log output which takes a lot longer.

Interesting debugging tip.

Logging output can include the class name, method name, and line number. I find going from log output to code in my IDE is a matter of one or two keystrokes. I find that logging is a lot faster than interactive debugging for finding issues in code, but I agree sometimes debugging is useful for harder to solve issues.

I feel old. I did trap debugging in the 80's using INT 3 (and still do on wintel/asm)

Thanks for sharing your experience.

I must raise some questions however.

1. How useful is trapping in a production environment where the problem occurs in the middle of the night when the administrator is sleeping (I am probably missing something here)?

2. How does it help me as a user to see this debugger?

I believe in both cases, logging is a lot more useful (if done correctly) than trapping. I can ask both the admin and the user to just send me the log file.

If we do proper TDD, we would have been writing the test first before actually implementing a behavior. Trapping will probably not add much in cases like these.