flow.
"Flow is a condition of deep, nearly meditative involvement." - Tom DeMarco

Overriding ToString for Easier Debugging

Wednesday, August 29, 2007 11:50 AM
Here's a quick trick to help you out in debugging which a lot of people forget.

When you're viewing one of your own objects in the Visual Studio, either through one of the watch windows or simply by hovering over the object in the editor, you'll often simply see the type name of the object which doesn't really tell you that much.

What's happening?  Well, under the covers the debugger is actually calling the ToString() method on your object which, unless you've overrode it, only displays the qualified type name of your object.

Imagine that you have a collection of Customer objects that you are trying to sort, only every time that you examine the list of Customers you can't discern anything meaningful because all of the objects look alike...



Not much help is it?  But wait, if the debugger simply calls the ToString() method on every object then we can simply override the method to return us something useful...like the name.  By simply overriding the method to do exactly that...

        /// <summary>
        /// Returns a <see cref="T:System.String"/> that represents the current <see 
        /// cref="T:System.Object"/>.  In this case, the current value of the <see cref="Name"/> 
        /// property is returned.
        /// </summary>
        /// <returns>A <see cref="T:System.String"/> that represents the current <see 
        /// cref="T:System.Object"/>.</returns>
        public override string ToString()
        {
            return Name;
        }


We get a readout that we can easily make much more sense out of...



Now all of those shady looking objects in your debugger can finally start to come into focus.

kick it on DotNetKicks.com

Feedback

# re: Overriding ToString for Easier Debugging

Excellent tip! Thanks 8/29/2007 4:39 PM | John S.

 re: Overriding ToString for Easier Debugging

If you don't want to (or cant) use the ToString() method you can also use the DebuggerDisplayAttribute:

e.g.:
[DebuggerDisplay("Customer: Name = {Name}")]
class Customer {...} 8/30/2007 2:12 AM | Bengt B.

 re: Overriding ToString for Easier Debugging

Yeah, I was going to suggest DebuggerDisplay, especially if you are only doing it for the sake of debugging. 8/30/2007 6:11 AM | Carl

 re: Overriding ToString for Easier Debugging

Something else that's cool about DebuggerDisplay that you couldn't do with ToString() (well it may be cool, but whether you'd want to do it or not I'm not sure!):

public class NewClass
{
private List<string> _stuff = new List<string>(new string[] { "First", "Middle", "Last" });

[DebuggerDisplay("{StuffDebugInfo}")]
public List<string> Stuff
{
get { return _stuff; }
set { _stuff = value; }
}

[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private string StuffDebugInfo
{
get
{
string res = _stuff.Count + " items";

if (_stuff.Count > 0)
{
res += ", First item: '" + _stuff[0] + "', Last item: '" + _stuff[_stuff.Count - 1] + "'";
}
return res;
}
}
}

If you create an instance of NewClass and then view it with the debugger, you get:

Stuff :- 3 items, First item: First, Last item: Last

I guess this could be pretty powerful stuff if you wanted to use it, but whether it's too much I'll leave you to decide! If you need to put this much info in, I think that you are probably bordering on requiring a custom DebuggerVisualizer.

Carl 8/30/2007 6:40 AM | Carl

# re: Overriding ToString for Easier Debugging

Thanks for the tips on the DebuggerDisplay attribute guys...I didn't know that!

Jeremy 8/30/2007 9:22 AM | Jeremy

Post a comment





 

Please add 8 and 6 and type the answer here: