Are virtual members called via reflection (in normal circumstances)?

Are virtual members called via reflection (in normal circumstances)? - c#

I was testing the effects of calling a virtual member in a constructor, and discovered that when calling that member the resulting exception was wrapped within a TargetInvocationException.
According to the docs this is:
The exception that is thrown by methods invoked through reflection
However I'm unaware of any invokations via reflection. So does this mean virtual members are always called via reflection? If not why is it so in this case?
The code:
class ClassA
{
public ClassA()
{
SplitTheWords();
}
public virtual void SplitTheWords()
{
//I've been overidden
}
}
class ClassB : ClassA
{
private readonly String _output;
public ClassB()
{
_output = "Constructor has occured";
}
public override void SplitTheWords()
{
String[] something = _output.Split(new[]{' '}); //TargetInvocationException!
}
}

No, virtual methods are called via virtual dispatch.
Reflection is not being used here. And nor is it for any virtual method calls. I believe the documentation for the exception is slightly misleading in that exceptions of this type are thrown by methods invoked via reflection, however not exclusively so.
If anyone is curious as to why the code in the question gives an exception, it is because of the order in which the constructors are executed. The ClassB constructor is the same as:
public ClassB() : base()
{
_output = "Constructor has occured";
}
Note the call to base(), this calls the base constructor before the ClassB constructor is run and, hence, before _output is assigned. The SplitTheWords virtual method is called in the base constructor, which resolves to ClassB.SplitTheWords. This method attempts to use _output, hence the error.
For a more detailed look at why virtual methods should not be called from constructors this SO question has some useful information. Eric Lippert also has a very good blog post on why this is the case here.

Are virtual members called via reflection (in normal circumstances)?
NO.
Nor from a constructor, so something else is going on. It would help to see the code calling the code you have shown and the stack trace from the exception.

Related

"Virtual member call in a constructor" caused by abstract members [duplicate]

I'm getting a warning from ReSharper about a call to a virtual member from my objects constructor.
Why would this be something not to do?

When an object written in C# is constructed, what happens is that the initializers run in order from the most derived class to the base class, and then constructors run in order from the base class to the most derived class (see Eric Lippert's blog for details as to why this is).
Also in .NET objects do not change type as they are constructed, but start out as the most derived type, with the method table being for the most derived type. This means that virtual method calls always run on the most derived type.
When you combine these two facts you are left with the problem that if you make a virtual method call in a constructor, and it is not the most derived type in its inheritance hierarchy, that it will be called on a class whose constructor has not been run, and therefore may not be in a suitable state to have that method called.
This problem is, of course, mitigated if you mark your class as sealed to ensure that it is the most derived type in the inheritance hierarchy - in which case it is perfectly safe to call the virtual method.

In order to answer your question, consider this question: what will the below code print out when the Child object is instantiated?
class Parent
{
public Parent()
{
DoSomething();
}
protected virtual void DoSomething()
{
}
}
class Child : Parent
{
private string foo;
public Child()
{
foo = "HELLO";
}
protected override void DoSomething()
{
Console.WriteLine(foo.ToLower()); //NullReferenceException!?!
}
}
The answer is that in fact a NullReferenceException will be thrown, because foo is null. An object's base constructor is called before its own constructor. By having a virtual call in an object's constructor you are introducing the possibility that inheriting objects will execute code before they have been fully initialized.

The rules of C# are very different from that of Java and C++.
When you are in the constructor for some object in C#, that object exists in a fully initialized (just not "constructed") form, as its fully derived type.
namespace Demo
{
class A
{
public A()
{
System.Console.WriteLine("This is a {0},", this.GetType());
}
}
class B : A
{
}
// . . .
B b = new B(); // Output: "This is a Demo.B"
}
This means that if you call a virtual function from the constructor of A, it will resolve to any override in B, if one is provided.
Even if you intentionally set up A and B like this, fully understanding the behavior of the system, you could be in for a shock later. Say you called virtual functions in B's constructor, "knowing" they would be handled by B or A as appropriate. Then time passes, and someone else decides they need to define C, and override some of the virtual functions there. All of a sudden B's constructor ends up calling code in C, which could lead to quite surprising behavior.
It is probably a good idea to avoid virtual functions in constructors anyway, since the rules are so different between C#, C++, and Java. Your programmers may not know what to expect!

Reasons of the warning are already described, but how would you fix the warning? You have to seal either class or virtual member.
class B
{
protected virtual void Foo() { }
}
class A : B
{
public A()
{
Foo(); // warning here
}
}
You can seal class A:
sealed class A : B
{
public A()
{
Foo(); // no warning
}
}
Or you can seal method Foo:
class A : B
{
public A()
{
Foo(); // no warning
}
protected sealed override void Foo()
{
base.Foo();
}
}

In C#, a base class' constructor runs before the derived class' constructor, so any instance fields that a derived class might use in the possibly-overridden virtual member are not initialized yet.
Do note that this is just a warning to make you pay attention and make sure it's all-right. There are actual use-cases for this scenario, you just have to document the behavior of the virtual member that it can not use any instance fields declared in a derived class below where the constructor calling it is.

There are well-written answers above for why you wouldn't want to do that. Here's a counter-example where perhaps you would want to do that (translated into C# from Practical Object-Oriented Design in Ruby by Sandi Metz, p. 126).
Note that GetDependency() isn't touching any instance variables. It would be static if static methods could be virtual.
(To be fair, there are probably smarter ways of doing this via dependency injection containers or object initializers...)
public class MyClass
{
private IDependency _myDependency;
public MyClass(IDependency someValue = null)
{
_myDependency = someValue ?? GetDependency();
}
// If this were static, it could not be overridden
// as static methods cannot be virtual in C#.
protected virtual IDependency GetDependency()
{
return new SomeDependency();
}
}
public class MySubClass : MyClass
{
protected override IDependency GetDependency()
{
return new SomeOtherDependency();
}
}
public interface IDependency { }
public class SomeDependency : IDependency { }
public class SomeOtherDependency : IDependency { }

Yes, it's generally bad to call virtual method in the constructor.
At this point, the objet may not be fully constructed yet, and the invariants expected by methods may not hold yet.

Because until the constructor has completed executing, the object is not fully instantiated. Any members referenced by the virtual function may not be initialised. In C++, when you are in a constructor, this only refers to the static type of the constructor you are in, and not the actual dynamic type of the object that is being created. This means that the virtual function call might not even go where you expect it to.

Your constructor may (later, in an extension of your software) be called from the constructor of a subclass that overrides the virtual method. Now not the subclass's implementation of the function, but the implementation of the base class will be called. So it doesn't really make sense to call a virtual function here.
However, if your design satisfies the Liskov Substitution principle, no harm will be done. Probably that's why it's tolerated - a warning, not an error.

One important aspect of this question which other answers have not yet addressed is that it is safe for a base-class to call virtual members from within its constructor if that is what the derived classes are expecting it to do. In such cases, the designer of the derived class is responsible for ensuring that any methods which are run before construction is complete will behave as sensibly as they can under the circumstances. For example, in C++/CLI, constructors are wrapped in code which will call Dispose on the partially-constructed object if construction fails. Calling Dispose in such cases is often necessary to prevent resource leaks, but Dispose methods must be prepared for the possibility that the object upon which they are run may not have been fully constructed.

One important missing bit is, what is the correct way to resolve this issue?
As Greg explained, the root problem here is that a base class constructor would invoke the virtual member before the derived class has been constructed.
The following code, taken from MSDN's constructor design guidelines, demonstrates this issue.
public class BadBaseClass
{
protected string state;
public BadBaseClass()
{
this.state = "BadBaseClass";
this.DisplayState();
}
public virtual void DisplayState()
{
}
}
public class DerivedFromBad : BadBaseClass
{
public DerivedFromBad()
{
this.state = "DerivedFromBad";
}
public override void DisplayState()
{
Console.WriteLine(this.state);
}
}
When a new instance of DerivedFromBad is created, the base class constructor calls to DisplayState and shows BadBaseClass because the field has not yet been update by the derived constructor.
public class Tester
{
public static void Main()
{
var bad = new DerivedFromBad();
}
}
An improved implementation removes the virtual method from the base class constructor, and uses an Initialize method. Creating a new instance of DerivedFromBetter displays the expected "DerivedFromBetter"
public class BetterBaseClass
{
protected string state;
public BetterBaseClass()
{
this.state = "BetterBaseClass";
this.Initialize();
}
public void Initialize()
{
this.DisplayState();
}
public virtual void DisplayState()
{
}
}
public class DerivedFromBetter : BetterBaseClass
{
public DerivedFromBetter()
{
this.state = "DerivedFromBetter";
}
public override void DisplayState()
{
Console.WriteLine(this.state);
}
}

The warning is a reminder that virtual members are likely to be overridden on derived class. In that case whatever the parent class did to a virtual member will be undone or changed by overriding child class. Look at the small example blow for clarity
The parent class below attempts to set value to a virtual member on its constructor. And this will trigger Re-sharper warning, let see on code:
public class Parent
{
public virtual object Obj{get;set;}
public Parent()
{
// Re-sharper warning: this is open to change from
// inheriting class overriding virtual member
this.Obj = new Object();
}
}
The child class here overrides the parent property. If this property was not marked virtual the compiler would warn that the property hides property on the parent class and suggest that you add 'new' keyword if it is intentional.
public class Child: Parent
{
public Child():base()
{
this.Obj = "Something";
}
public override object Obj{get;set;}
}
Finally the impact on use, the output of the example below abandons the initial value set by parent class constructor.
And this is what Re-sharper attempts to to warn you, values set on the Parent class constructor are open to be overwritten by the child class constructor which is called right after the parent class constructor.
public class Program
{
public static void Main()
{
var child = new Child();
// anything that is done on parent virtual member is destroyed
Console.WriteLine(child.Obj);
// Output: "Something"
}
}

Beware of blindly following Resharper's advice and making the class sealed!
If it's a model in EF Code First it will remove the virtual keyword and that would disable lazy loading of it's relationships.
public **virtual** User User{ get; set; }

There's a difference between C++ and C# in this specific case.
In C++ the object is not initialized and therefore it is unsafe to call a virutal function inside a constructor.
In C# when a class object is created all its members are zero initialized. It is possible to call a virtual function in the constructor but if you'll might access members that are still zero. If you don't need to access members it is quite safe to call a virtual function in C#.

Just to add my thoughts. If you always initialize the private field when define it, this problem should be avoid. At least below code works like a charm:
class Parent
{
public Parent()
{
DoSomething();
}
protected virtual void DoSomething()
{
}
}
class Child : Parent
{
private string foo = "HELLO";
public Child() { /*Originally foo initialized here. Removed.*/ }
protected override void DoSomething()
{
Console.WriteLine(foo.ToLower());
}
}

I think that ignoring the warning might be legitimate if you want to give the child class the ability to set or override a property that the parent constructor will use right away:
internal class Parent
{
public Parent()
{
Console.WriteLine("Parent ctor");
Console.WriteLine(Something);
}
protected virtual string Something { get; } = "Parent";
}
internal class Child : Parent
{
public Child()
{
Console.WriteLine("Child ctor");
Console.WriteLine(Something);
}
protected override string Something { get; } = "Child";
}
The risk here would be for the child class to set the property from its constructor in which case the change in the value would occur after the base class constructor has been called.
My use case is that I want the child class to provide a specific value or a utility class such as a converter and I don't want to have to call an initialization method on the base.
The output of the above when instantiating the child class is:
Parent ctor
Child
Child ctor
Child

I would just add an Initialize() method to the base class and then call that from derived constructors. That method will call any virtual/abstract methods/properties AFTER all of the constructors have been executed :)

Another interesting thing I found is that the ReSharper error can be 'satisfied' by doing something like below which is dumb to me. However, as mentioned by many earlier, it still is not a good idea to call virtual properties/methods in constructor.
public class ConfigManager
{
public virtual int MyPropOne { get; private set; }
public virtual string MyPropTwo { get; private set; }
public ConfigManager()
{
Setup();
}
private void Setup()
{
MyPropOne = 1;
MyPropTwo = "test";
}
}

Why can't serialization callback methods be virtual?

I have a deserialization method (decorated with the [OnDeserialized()] attribute) which I want to override in a derived class. When I try to do so, I get the following runtime error:
An unhandled exception of type 'System.TypeLoadException'....
Type 'BaseObj' in assembly ... has method 'OnDeserialization' which is either static, virtual, abstract or generic, but is marked as being a serialization callback method.
I couldn't find any documentation confirming this restriction on serialization callbacks (other than the error message itself). Can anyone explain this strange limitation?
Based on a suggestion in a comment here, I resorted to calling a separate virtual function from the OnDeserialization method, like so:
[Serializable()]
public class BaseObj
{
protected string obj { get; set; }
[OnDeserialized()]
public void OnDeserializedMethod(StreamingContext context)
{
//call the virtual method because deserialization callbacks can’t be virtual
onDeserialized(context);
}
virtual protected void onDeserialized(StreamingContext context)
{
obj = "This value was deserialized by the base class.";
}
}
[Serializable()]
public class DerivedObj : BaseObj
{
override protected void onDeserialized(StreamingContext context)
{
obj = "This value was deserialized by the derived class.";
}
}
This seems to work fine, but it seems rather "kludgey". Is this really my only option? Why can't a serialization callback method be virtual?

Since BinaryFormatter and DataContractSerializer don't call constructors when deserializing, OnDeserializedAttribute allows performing of operations you would normally do in a constructor, e.g. state initialization. Methods marked by this attribute are also executed in the same order constructors are: base first, then derived.
So for the purposes of deserialization you can treat those methods as constructors.
And virtual constructors are not allowed in C#.

I am facing same issue, and I saw this question. So I did some test, and I got some interesting findings, and I think I figured out why virtual is not needed from a different angle.
Here is my test.
[DataContract]
class Base
{
[OnDeserialized]
//cannot be virtual
protected void OnDeserializedBase()
{
//base deserialization
}
}
[DataContract]
public class Derived : Base
{
[OnDeserialized]
//cannot be virtual
OnDeserializedDerived()
{
//Derived deserialization
}
}
Base b = new DataContractJsonSerializer(typeof(Derived)).ReadObject(stream);
What I find is, both OnDeserializedBase and OnDeserializedDerived will be invoked, in turns. Even if there is NO OnDeserialized in the derived class, Base class's OnDeserializedBase will still be invoked.
If that is the case, it makes no benefit from making this method virtual. Because, to get the benefit of a virtual method, you need to pass a derived object into base object, and call that base.virtualMethod(). There is never a chance to do it that way. But, you don't need to worry about losing the OnDeserialized functionality even you deserialize a derived class.
So after the test, I am happly to do the way that I posted.

What type does the 'this' keyword actually refer to?

I have the following code
public class Base {
public Base() {}
public virtual void IdentifyYourself() {
Debug.Log("I am a base");
}
public void Identify() { this.IdentifyYourself(); }
}
public class Derived : Base {
public Derived() {}
public override void IdentifyYourself() {
Debug.Log("I am a derived");
}
}
I run the following test code in a different entrypoint:
Base investigateThis = new Derived();
investigateThis.Identify()
and the output is: "I am a derived"
So no matter where the C# 'this' keyword is used; does it always refer to the run-time type no matter what scope 'this' is used in?
Bonus points to anyone who was able to 'Google' better than me and find MSDN documentation on specifically 'this' (pun intended) behavior.
Lastly, does anyone happen to know what is happening under the hood? Is it just a cast?
Update #1: Fixed typo in code; With the current set of answers, I guess I did not fully understand the implications of what the MSDN documentation meant by "..is the current instance..".
Update #2: Apologies, I wasn't sure if I should have made a separate question, but on further investigation, I've confused myself again; given this updated code, why is the output both: "I am a derived" & "It is a base!".
Didn't other people answer that 'this' is indeed the run-time type? Let me know if my updated question still is not clear.
Updated code:
public class Base {
public Base() {}
public virtual void IdentifyYourself() {
Debug.Log("I am a base");
}
//Updated the code here...
public void Identify() { this.IdentifyYourself(); AnotherTake(); }
public void AnotherTake() { WhatIsItExactly(this); }
public void WhatIsItExactly(Derived thing) {
Debug.Log("It is a derived!");
}
public void WhatIsItExactly(Base thing) {
Debug.Log("It is a base!");
}
}
public class Derived : Base {
public Derived() {}
public override void IdentifyYourself() {
Debug.Log("I am a derived");
}
}

Absolutely! investigateThis refers to an instance of Derived.
So the virtual method IdentifyYourself in Derived will be called. This is run-time polymorphism in effect.
The scope does not matter.
Under the hood, an virtual function table is built, and there is a pointer in the object that points to that table.

if you google: c# this the following link is the first result returned.
https://msdn.microsoft.com/en-us/library/dk1507sz.aspx
The this keyword refers to the current instance of the class and is
also used as a modifier of the first parameter of an extension method.
You may also want to take a look at base while you are at it.
https://msdn.microsoft.com/en-us/library/hfw7t1ce.aspx
The base keyword is used to access members of the base class from
within a derived class:
Call a method on the base class that has been overridden by another
method.
Specify which base-class constructor should be called when creating
instances of the derived class.

'this' always refers to the current instance, whereas 'base' always refers to the inherited type, regardless of whether the code using 'this' is in the base or the child class, it will always refer to the child (unless the base is instantiated itself, of course). It's just a reference to the current instance, like 'self' in python. Useful if a parameter has the same name as a private field, but as far as I'm aware it has no functional purpose other than that, I use it for readability, to clearly show when something belongs to the class I'm working in.

MyClass equivalent in C#

In looking at this question, commenter #Jon Egerton mentioned that MyClass was a keyword in VB.Net. Having never used it, I went and found the documentation on it:
The MyClass keyword behaves like an object variable referring to the current instance of a class as originally implemented. MyClass is similar to Me, but all method calls on it are treated as if the method were NotOverridable.
I can see how that could kind of be useful, in some specific scenarios. What I can't think of is, how would you obtain the same behaviour in C# - that is, to ensure that a call to a virtual method myMethod is actually invoked against myMethod in the current class, and not a derived myMethod (a.k.a in the IL, invoking call rather than callvirt)?
I might just be having a complete mental blank moment though.

According to Jon Skeet, there is no such equivalent:
No, C# doesn't have an equivalent of VB.NET's MyClass keyword. If you want to guarantee not to call an overridden version of a method, you need to make it non-virtual in the first place.
An obvious workaround would be this:
public virtual void MyMethod()
{
MyLocalMethod();
}
private void MyLocalMethod()
{
...
}
Then you could call MyLocalMethod() when a VB user would write MyClass.MyMethod().

There is no C# equivalent of the MyClass keyword in VB.Net. To guarantee that an overridden version of a method will not be called, simply make it non-virtual.

In addition to answers saying it doesn't exist, so you have to make it non-virtual.
Here's a smelly (read: don't do this!) work-around. But seriously, re-think your design.
Basically move any method that must have the base one called into 'super'-base class, which sits above your existing base class. In your existing class call base.Method() to always call the non-overridden one.
void Main()
{
DerivedClass Instance = new DerivedClass();
Instance.MethodCaller();
}
class InternalBaseClass
{
public InternalBaseClass()
{
}
public virtual void Method()
{
Console.WriteLine("BASE METHOD");
}
}
class BaseClass : InternalBaseClass
{
public BaseClass()
{
}
public void MethodCaller()
{
base.Method();
}
}
class DerivedClass : BaseClass
{
public DerivedClass()
{
}
public override void Method()
{
Console.WriteLine("DERIVED METHOD");
}
}

What are the dangers of making a method virtual?

I've been doing some mocking with RhinoMocks and it requires that mocked methods be made virtual. This is fine except we have a custom framework which contains the methods that I want to mock which are currently not marked as virtual.
I can't forsee any problem with making these methods virtual but I was wondering what are some potential dangers of making methods virtual that I should look out for?

Actually it can be very problematic if the method is not designed to be overridden and someone overrides it. In particular, never call a virtual method from a constructor. Consider:
class Base {
public Base() {
InitializeComponent();
}
protected virtual void InitializeComponent() {
...
}
}
class Derived : Base {
private Button button1;
public Derived() : base() {
button1 = new Button();
}
protected override void InitializeComponent() {
button1.Text = "I'm gonna throw a null reference exception"
}
}
The Derived class may not be aware that the virtual method call will result in its InitializeComponent method being called before a single line of its own constructor has run.

If you have users that override your virtual methods you can't seal them again without breaking code.
Any virtual methods you call from the constructor may fall down to derived implementations and if they don't call the base method and the constructor depends on it, the object may be in an invalid state

Ayende has a nice treatment of how virtual methods work:
http://ayende.com/Blog/archive/2007/01/05/HowVirtualMethodsWork.aspx

Develop Reference

C# (C-Sharp) is a programming language developed by Microsoft that runs on the .NET Framework.

Are virtual members called via reflection (in normal circumstances)? - c#

Are virtual members called via reflection (in normal circumstances)? NO. Nor from a constructor, so something else is going on. It would help to see the code calling the code you have shown and the stack trace from the exception.

Related

"Virtual member call in a constructor" caused by abstract members [duplicate]

Why can't serialization callback methods be virtual?

What type does the 'this' keyword actually refer to?

MyClass equivalent in C#

What are the dangers of making a method virtual?

Categories

Resources