Please use .ToString() responsibly

I've seen this kind of code a lot recently:

This results in the following output:

This is a companion discussion topic for the original blog entry at:

Hear, Hear!

(Clink of beer mugs)

I completely agree, my conservative friend - and I support the liberal use of ascii art in my ToString overrides.

Also, wanted to share what I used on my last campaign for debugging DataSets in VS.NET 2003:

a href=""

This plug-in offers a great visualization of any xml-serializable type during debugging.

I’ve tried the ToString() methods you’ve suggested before, but C#'s Immediate command window doesn’t give a pretty representation of newlines, once again making VB.NET the choice of progressives everywhere.

but C#'s Immediate command window doesn’t give a pretty representation of newlines,

This drives me crazy! Is there a way to get the C# immediate window to echo \n as a real newline within strings?

I agree with the sentiment - it bugs me when .toString == .Type.ToString. The problem with the DataSet idea is what you do when the underlying object is large. I don’t really want a 2GB string returned when I go DataSet.ToString()

Sure, you can tweak it, but I wonder about whether it’s even possible to come up with useful guidelines. What sort of metadata to return… DataWareHouse.ToString – “Zurich DataWareHouse: 43.6TB in 2563 tables, 3.7T rows” beats nothing I suppose.

Of course, the sanity of someone calling ToString on some objects is a little questionable, given what it’s normall expected to do.

Seems perfectly logical to me, but you’ll have
to write your own custom ToString()
implementation to get the behavior that should
have been there in the first place.

FWIW, there’s an ASCII table generator here:

a href=""

When shouldn’t you spit out a verbose error message? When you’re working on a networked component, like a website or anything that interacts with a database. It’s a thousand times easier to find and exploit a SQL injection attack if you get verbose errors. If you tell me where and why your website rejected or crashed on my input, I’ve learned more about your system and I’m one step closer to cracking it.

If you’re shipping it, be terse - “an error occurred, sorry buddy.” Don’t give your attacker anything useful: you’ll slow them down a bit. In fact, do it right - make your catch block call a function that can report terse, report verbose, or log everything possible. That way, if you need to investigate a customer escalation, you can switch em to super verbose diagnostic mode and go from there.

Also - I don’t know how much control you have over this blog software, but you should disable the “email address” requirement. Just using this post’s comments as an example, of the six unique responders, three used fake email address, two used a blog URL instead of an email address, and only one person used a real one.

“any object you build should have a meaningful .ToString() method”

I have to disagree. Any well structured object system separates the concept of the formatter (ToString) with the data representation (myObject). Any arbitrary ToString() implementation that I may provide is only one of many possibilities, and largely pointless unless I have a specific use in mind.

In addition, by committing early to a specific implementation, I would be making that implementation part of my interface. Thus, I no longer have the freedom to change that implementation to something useful at a later stage.

No thanks, I’ll stick with the default implementation.

The problem with the “stack trace” on error is that you end up with the python problem … where a significant number of errors a user can see end up with 25+ line stack traces instead of “Can’t create file: X”, “hostname X not found”, or “Network connection failed”.
This is a problem in general with throwing “exceptions” everywhere, it’s often documented very badly what you should be catching where.

I thought I’d point to Ned Batchelder’s article on Stringification:

Though he’s talking about Java, the same hold true for C# and other languages.

I just learned (from playing) that in Managed DirectX, when handling exceptions, .ToString() is your best friend =o)

.Message will always give something like “error in application”

Yet another reason to implement .ToString() –


In the context of the example, don’t use ToString(). If you are using Console.Write() or Console.WriteLine(), or string.Format() for that matter, just say:


Let WriteLine handle calling ToString() for you. :wink: