« Help file link in ASP.NET | Main | Delete confirm in asp:GridView »

12/12/2010

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a0115711bf0ae970b0147e09dd4a8970b

Listed below are links to weblogs that reference One of the Most Powerful Debugging Practices:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

I am not sure I understood what you are trying to elucidate here. I have been reading Trap.java and all I can see are methods that throw a RuntimeException. How is that going to help? Cheers :)

Hi Jeune;

You need to set your debugger to break on a handled case of TRAP being thrown. You also need to set TRAP.debugMode = true.

Wouldn't it make more sense to use coverage tools similar to Cobertura in Java? Every line of code not executed by your tests gets highlighted.
I am less familiar with .Net alternatives, but heard of PartCover and NCover

Hi Alex;

If your only concern is code coverage, then yes Cobertura will also get the job done. However, I think the most powerful part of this practice is single stepping through each code segment the first time you hit it - and a code coverage tool will not provide that functionality.

Just an FYI, I can't use your TRAP.java since I have no relationship or licensing agreement with "Windward Studios, Inc.".

Hi Will;

Sorry about that. I just changed the link to trap.zip which has the java and c# versions with a full public/any use license.

Hi David;
Please let me know the option you refer to using which you put that as ** ?

Hi Ragav;

I mean just type in **. So if the code was

x = 3;
Trap.trap();
y = 2;

Then after I hit the trap, if the code there all works right and I want to delete it the next time I compile, I type ** so you have:

x = 3;
** Trap.trap();
y = 2;

Now every line number in the debugger is still good. But when I end my debugging session and go to rebuild the code, that line will not compile. I go to the compile failure and delete that line.

Well, you should try Unit tests with some nice coverage tool ;D

Debugging is really hard, and most of the time, only needed if you write something really bad or really complicated (complicated is evil).

In your example, you can check all with proper unit tests and mocks. Much better than debug, because it will stay with code for next changes.

hate to nitpick, but the text format around your image makes the article hard to read.

The comments to this entry are closed.

David Thielen

B.I. Tweets

    follow me on Twitter

    Windward Reports

    Quantcast

    • Quantcast