Should I use the Debug class in .net?

Question

I've been reading a lot about the Debug class lately.

I'm pretty torn about it personally. I can see it improving the process of creating really tricky algorithms. But it also adds a lot of code to my app that I have to wade through unnecessarily. Having a Debugger should remove the need for boiler plate code, whether it is stripped out for a release build automatically or not right?

I am also interested in how those of you that do put the Debug class to good use are doing it. Do you write Debug.Assert statements at all, or do you agree with Ed Kaim that Debug.WriteLine and Debug.Fail are all you should use.

Answer 1

I personally agree with Ed Kaim. Personally, I feel like good testing practices have replaced Debug.Assert calls in all of my work. In addition, I have pretty much abandoned my use of Debug.Fail as well - any time I want to use this, I pretty much find that I want to throw an exception in release as well as debug, so I don't typically see the point.

That being said, I do still use some of the debug printing statements to augment my debugging (via Debug.WriteLine), especially in numerical code... I acknowledge that it's a throwback to old-school printf debugging, but often, that's still the fastest way to track down a problem, especially one that doesn't show up in the debugger (due to timing issues, threading, etc).

Answer 2

We use Debug.Assert very often - for every important assumption that you would make it does not harm to have an Assert.

Quite a useful but old article - IDesign C# Coding Standards here

Answer 3

Debug.Assert test for contract. It has a little benefit that it is not present in release code. That is not the case with if + throwing exception case.

I use Debug.WriteLine for UI events because there debugger gets in the way (e.g refresh events are called again when switching from VS window to app window).

Answer 4

The main advantage of using the Debug class over simply running code in you debugger is that you get a log file (using Debug.Writeline statements), which you can share with colleagues/store for your records.

The advantages that Debug.Assert has over writing a separate test method are compactness, and the fact that the check is in exactly the place it needs to be, rather than a separate method.

Answer 5

Hi there.

Personally, I rarely use the Debug class at all for any of my programming. I've read a lot of comments and suggestions, such as those by John Robbins (author of Debugging .NET 2.0 Applications and the Bugslayer columns) about why you should be asserting proactively - especially parameters for methods.

The problem I have is this - say I was to write code like this:

Public Sub Test(source As Object)

  Debug.Assert(source IsNot Nothing, "source is Nothing")

  ' Do something....
End Sub

This works well during development with debug builds, but I end up doing this anyway:

Public Sub Test(source As Object)

  If source IsNot Nothing Then

  ' Do something....

  End If
End Sub

If there's a chance for 'source' to be nothing, then I'm going to do an 'If' check on it anyway. I'm not going to leave the assert call in the release build.

The other reason I don't use the Debug class is that I write a lot of unit tests. Doing so has led me to covering a lot of code paths, thus having a Debug.Assert in my code is not required.

As for debug logging, then I simply use Trace calls and SysInternals DebugView or text files to log the output of trace calls.

I would love to hear from others on this topic, since I'm also interested in knowing how they might be using the Debug class during development. It's an area I don't have much experience in, so I'm eager to learn.

Cheers. Jas.

Answer 6

My own opinion is that Debug.Assert and Debug.Fail are often misused to "hide" errors from end-users. I'd rather write to an error log or throw an exception if warranted.

Answer 7

I can't tell you if you should, but I can suggest times when I use it.

I use Debug when I want more information about a function/variable/process/result but I know once it's released that info is no longer relevant. I use Debug.Writeline to verify correct chronology of a process, for example, or Debug.Assert to verify a value is what it should be.

I think Kaim is just saying it's easy to misuse Debug.Assert. Don't use Debug.Assert to catch issues that could occur in production. Debug.Assert is meant for simple checks during development, like a reminder flag. It is not meant to handle release-code errors. You can put a Debug.Assert every other line without worrying it is slowing down the release code.

Answer 8

I would suggest not to use the Debug class at all; I don't. Generally, I find for development that the debugger is good enough for all of my needs; and what I really need to track, I log. The most critical part about logging is that the logging also occurs in production code, which can be absolutely important. Debug by definition is only functional in debug code; while it might be useful for helping you find something during development, if it's that important to find, log it. Seriously. If it's important to find and tricky enough that you need a special facility to get to it, log it; it's likely to show up in your production environment as an edge case, and what will you do then?

And for what it's worth, I find log4net to be incredibly useful and robust for logging purposes. I'd recommend its use over the use of the Debug class any day.