Recently my application (C#) crashed with an exception of type 'System.StackOverflowException'. Strange, since nothing had been changed in my source code, what has happened? After investigation, the only thing that changed was the version of a library referenced by my application (I have found my criminal). I isolated the origin of the change, of course a class from the used library. Without the source code of the library, I used JetBrains DotPeek to inspect the library’s assembly and I found the problem origin. That arose from a library base class that my code inherits.
I'm going represent this situation with a simple example in C#.
My source code where nothing changes:
using System;
class MyApp
{
static void Main(string[] args)
{
MyDerivedClass obj1 = new MyDerivedClass();
Console.WriteLine("{0}", obj1.ToString());
}
}
My derived class:
class MyDerivedClass : LibBaseClass
{
public override string ToString()
{
return ":> MyDerivedClass.ToString()." + base.MyMethod();
}
}
The library base class used by my application:
class LibBaseClass
{
public string MyMethod()
{
return this.ToString();
}
}
Run this code and you will have a stack overflow error like me.The ToString() method of MyDerivedClass makes a recursive call because it overrides the ToString() method of the highest base class, object.The solution is to break this virtual propagation in the framework, with the C# keyword "new" (keyword "Shadows" in VB.NET), like following:
class MyDerivedClass : LibBaseClass
{
public new string ToString()
{
return "MyDerivedClass.ToString()." + base.MyMethod();
}
}
If you look at the IL code the method is not virtual anymore. This kind of problem is know as the "Fragile Base Class", you can find lots of articles on the web about it. In our case the result of this behavior crashes the application. But the consequences can be more vicious and difficult to identify. For Example the application continues to run but returns a wrong result. You can imagine the danger of this behavior! The best way to prevent or minimize this kind of error, is to rely on quality unit testing.