Converting to string

[Shaggy Hiker]

Here's a general question. I have some code that was generated via templates. In general, wherever an object needed to be turned into a string, the templates used CStr(). This works fine for nearly everything...until I switched a field to a GUID, at which point CStr() throws an exception. Using .ToString works fine for GUIDs, and I can't think of any situation where .ToString will fail when CStr() would work. All of the items that are being passed in are fields in a datarow, datagridviewrow, pure objects (that are generally fields from datarows), or something like that. Am I overlooking a situation?

[Tom Sawyer]

Everything in .NET inherits from System.Object, so everything in .NET has the ToString method available to it, therefore it should never fail on you except if the object isn't set to anything and it throws the null reference exception because you're trying to call a method of it. CStr is a holdover from classic VB and, while it works in most cases, isn't really part of the .NET Framework and it isn't the best practice to use it instead of ToString.

[wild_bill]

I don't think the .NET objects will ever throw an exception while calling .ToString. Also, the situation you described will also occur when converting dbnull types, rather than calling ToString. I beleive the positive for converting rather than .ToString is performance.

[Shaggy Hiker]

I haven't tested performance, but the negative (total failure) outweighs any performance benefit.

[jmcilhinney]

Everything in .NET inherits from System.Object, so everything in .NET has the ToString method available to it, therefore it should never fail on you except if the object isn't set to anything and it throws the null reference exception because you're trying to call a method of it.

Correct.

CStr is a holdover from classic VB and, while it works in most cases, isn't really part of the .NET Framework and it isn't the best practice to use it instead of ToString.

Not true at all. CStr is no more a holdover from VB6 than any other VB.NET keyword. It is NOT a Runtime function (a member of the Microsoft.VisualBasic namespace) like MsgBox or Len. It is part of the VB.NET language itself, hence it turns blue in the code window. The truth of the matter is that CStr(obj) is simply a shorthand for CType(obj, String).

It is NOT best practice to use ToString in preference to CStr. CStr is more efficient than ToString because it is compiled inline rather than as a function call. If you want to cast a reference to a String object as type String then CStr is preferable to ToString. If you want to convert an object for which the CType operator is defined for type String then CStr is preferable to ToString. If you want to convert an object that is not a String, and for which the CType operator is not defined for type String, to a String representation then ToString is the only option.

[Shaggy Hiker]

This is generated code, so the type of the object is not known so well. After a bit of discussion we realized that no approach was correct for all cases. If you write a function that turns an object into a string, there are cases where either CStr or .ToString will raise exceptions. Therefore, we will be writing something that will handle the correct types the correct ways to the extent that that is possible for template based programs.

[jmcilhinney]

If the type is not known the I think all you'd have to do is test for a null reference. Use CStr if it is and ToString otherwise. I can't think of a situation where that wouldn't work.