C#: Force Compiler error on use of myObj.ToString()

Question

I have a class that contains a bunch of properties. It is a mistake by a programmer if they call ToString() on an object of that type. Take this example code:

using System;

public class Foo
{
    public int ID = 123;
    public string Name = "SomeName";

    private string ToString() { return null; }
}

public class MyClass
{
    public static void Main()
    {
     Foo myObj = new Foo();
     WL("I want this to be a compiler error: {0}", myObj.ToString());
     RL();
    }

    #region Helper methods

    private static void WL(object text, params object[] args)
    {
     Console.WriteLine(text.ToString(), args); 
    }

    private static void RL()
    {
     Console.ReadLine(); 
    }

    #endregion
}

You could reason that if ID is what most people want written out as a string, then I should implement ToString so that it returns the ID. However, I believe that is a bad practice because programmers will "accidentally" get working code. A programmer using my class should specify what they want.

Instead, what I would like is if someone calls myObj.ToString() to have that show up as a compile time error. I thought I could do that by creating a private ToString() function, but that doesn't work.

The reason I brought this up is that we ended up with a query string that contained the fully qualified class name rather then an ID.

So the question is: Is there any way to "hide" the ToString() function so that calling it on an object of my class causes a compiler error?

Answer 1

The Obsolete attribute allows you to do this.

[Obsolete("Use the XYZ properties instead of .ToString() on Foobar", true)]

The boolean at the end is for whether the compiler should consider use of this member an error.

Answer 2

Use the override keyword with a public ToString() function to override the System.Object ToString() methiod.

Answer 3

I cannot stress enough how bad an idea this design is.

ToString() is part of the object contract in .Net. If you don't want to implement it then don't override it, and just let it return the type info. What harm could that possible cause?

I don't mean to be so negative, but I am absolutely floored that someone would want to get rid of ToString().

Some additional points:

1. Why do the programmers using this class assume that ToString() will return an ID? Are other classes in your ecosystem doing this? One can argue that ToString() should return some meaningful data. But you really shouldn't be programming against the results of a ToString() call. ToString() is for a string representations of the class, period. This sounds like an education or communication issue between programmers or departments.
2. Crippling ToString() in any way, whether you can figure out how to at compile time or by throwing an exception at run time, will have ripples. I have never seen this done, and would not expect any class I am using to exhibit this behavior. I think most programmers would have the same expectations. Will future programmers that use your class expect this? What bugs and maintenance nightmares are you causing down the road?
3. What impact does this have in the IDE or debugger, which rely on ToString()?
4. What impact will this have when using databinding technologies that don't bind against a specific type, but use reflection at run-time to pull out values? Most databinding will fall back to calling ToString() on an object if a member is not specified to use.

Answer 4

Override ToString to return string.Empty, then you wouldn't have anything appended to the query string. By default if you don't override ToString you'll get Object's version which returns this.GetType() which will give you something like the namespace and class name.

Calling ToString seems a pretty reasonable thing to do, I wouldn't want to raise complier errors for someone doing that.

Answer 5

This is interesting - I would have expected your code to produce a compile time error because Foo.ToString() method in the Foo class is private.

I understand that the Foo.ToString() does not override System.Object.ToString(), it hides the inherited ToString(). However, in your example ToString() is being called on a Foo reference, so I would have thoght that the private access modifier would apply here.

If ToString() were called via a System.Object reference a completely different ToString() method would be invoked. In that case,System.Object.ToString() would be invoked and the type name would be returned.

But why doesn't the C# compiler respect the private access modifier when calling through a Foo reference? Can anyone explain?

Answer 6

In Response to Jason Jackson:

I see what you are saying, but I think there is a trade-off involved. On one hand, why can't I control what functions are apart of my class? More importantly, why shouldn't I be able to spot programming errors at compile time rather then run time?

To answer your question about what harm could be caused: well, nothing majors, but it's just more bugs/problems to flesh out during development. It's type info in query strings, sent to the database, etc, where someone mistyped something. Yes, in an ideal world, that would never happen and the code should be fixed and eventually it will.

Can you better explain the "object contract in .Net" that you speak of? What harm can marking ToString as Obsolete possibly cause?

Answer 7

I completely disagree with using the Obsolete property for this for a few reasons.

To start with you will now have a warning for the ToString() method that you overrode and tagged with the Obsolete property:

    [Obsolete("dont' use", true)]
    public override string ToString()
    {
        throw new Exception("don't use");
    }

yields this warning: Warning 1 Obsolete member 'ClassLibrary1.Foo.ToString()' overrides non-obsolete member 'object.ToString()' d:\source\ClassLibrary1\ClassLibrary1\Class1.cs 11 32 ClassLibrary1

so now you are stuck with a permanent warning in your code. On top of this, it doesn't exactly solve your issue. What happens when something in the framework implicitly calls ToString() now? The result of the following code is that the code in the body of ToString() is still called:

        Foo myObj = new Foo();

        Console.WriteLine(myObj);

So now you have a warning in your code, and it doesn't actually prevent a developer from doing the same thing all over again. I think the right move here is to try to find a way to throw an appropriate exception at run time rather than trying to mess with the .net object contracts.

Suggestion for catching problem at compile time: I realized I had not previously given a suggestion for a solution for this issue. I don't really know what format your id is in for sure so I am only making a guess at it being an int, but why not protect whatever is creating the url with the querystring and pass the id as an int. That way a developer can't accidentally pass in some meaningless string without a compilation error. Like this for instance:

public string CreateItemUrl(int itemId)
{
   return string.Format("someurl.aspx?id={0}", itemId);
}

Now, calling this:

CreateItemUrl(myObj.Id);

becomes much more strongly typed and less error prone than:

string theUrl = string.Format("someurl.aspx?id={0}", myObj);

Answer 8

Please, consider your design/opinion to be changed :)

First of all, definition of Foo.ToString does not define an override for Object.ToString() but a new one and should be prefixed with "new" keyword to prevent misunderstanding of semantics. Or explicitly declare an "override". IMHO, compiler issues corresponding warning.

Even if you'll find a way to prohibit a call to Foo.ToString, it will be prohibited at compile time only when type of "this" is known to be Foo or descendant, but ((object) foo).ToString() will be a correct workaround, because ToString is a method of Object interface.

Also, preventing a call of ToString is undesirable since Debugger uses it to present a value. SY, Jake

Answer 9

Aside from the bad design idea of overriding ToString and returning null (instead of string.Empty or something else), I think most of the answers miss the main point of the question, which is: how to throw a custom compiler error? I've actually been interested about knowing this myself.

Answer 10

I'd take a hybrid approach. (Hey, isn't SO about combing other answers? :))

First, create a new ToString that returns void. No return value means they can't use it to get any accidentally nice code:

public new void ToString() { }

Next, add the Obsolete attribute so when people DO call it, they get a warning telling them ToString is bad.

You won't need to override ToString this way, simply hide it with something that's useless. The fact it has no return will break all code, hence causing a compiler error on top of the obsolete message.

People casting to Object are not your concern, if I understand your question directly. You don't want to prevent people from calling ToString and getting type info, you want to prevent them from accidentally thinking ToString provides a useful result.

Edit: Please don't throw an exception or override ToString. That would cause "bad things" when your object is treated as an object. Just using "new" allows the benefits you asked for, without screwing up other frameworks.