One of the Most Powerful Debugging Practices

The hard to find bugs generally occur under circumstances that are relatively rare. After all, if the program re-boots your system every time you run it, you will usually fix that error. Some of these rare cases are caused by executing a code path that has never been executed before. When your program first starts, you will generally create a number of objects. You have a code path you take if those constructors throw exceptions, but have they ever failed?

If not, you have an accident waiting to happen. What does your program actually do when that particular constructor fails? As long as you have not tested a code path, you have not fully tested your program. Be sure that you exercise every code path. If you have an "if () ... else ..." and you have always executed the "else" part, then the "if" part is a bug waiting to happen.

There is a very simple way to handle this, and do so in a manner that will help you as you first run your code. The beauty of using traps is it helps you immediately, so that you will quickly find that you automatically put them in as you write code.

This is composed of two methods, trap() and trap(bool) – I have included Java, C++, & assembler examples at the, but for illustration I will use C# here. What a trap does is drop you into the debugger when you hit one. First the example, then why this is so useful

// Open an XML file
XmlReader reader;
if (string.IsNullOrEmpty(username)) {
   Trap.Trap();
   reader = XmlReader.Create(filename, xmlSettings);
} else {
   Trap.Trap(!hasDomain);
   Trap.Trap(hasDomain);
   XmlUrlResolver resolver = new XmlZipResolver();
   resolver.Credentials = hasDomain ? new NetworkCredential(user, password, domain) : new NetworkCredential(user, password);
   xmlSettings.XmlResolver = resolver;
   reader = XmlReader.Create(filename, xmlSettings);
}

The Immediate Pay-Off

Why is this a big help from the start? Because it helps you single step through each part of your code once. In the code above you probably test at first with no username so you'll fall in the debugger on the first trap. You mark it and then step over the Create. You may single step a couple of lines after to make sure the xml is good, then you go.

Read more: Windward Wrocks

Posted via email from .NET Info