Due to a bug that was fixed in C# 4, the following program prints true
. (Try it in LINQPad)
void Main() { new Derived(); } class Base { public Base(Func<string> valueMaker) { Console.WriteLine(valueMaker()); } } class Derived : Base { string CheckNull() { return "Am I null? " + (this == null); } public Derived() : base(() => CheckNull()) { } }
In VS2008 in Release mode, it throws an InvalidProgramException. (In Debug mode, it works fine)
In VS2010 Beta 2, it doesn't compile (I didn't try Beta 1); I learned that the hard way
Is there any other way to make this == null
in pure C#?
This observation has been posted on StackOverflow in another question earlier today.
Marc's great answer to that question indicates that according to the spec (section 7.5.7), you shouldn't be able to access this
in that context and the ability to do so in C# 3.0 compiler is a bug. C# 4.0 compiler is behaving correctly according to the spec (even in Beta 1, this is a compile time error):
§ 7.5.7 This access
A this-access consists of the reserved word
this
.this-access:
this
A this-access is permitted only in the block of an instance constructor, an instance method, or an instance accessor.
The raw decompilation (Reflector with no optimizations) of the Debug mode binary is:
private class Derived : Program.Base { // Methods public Derived() { base..ctor(new Func<string>(Program.Derived.<.ctor>b__0)); return; } [CompilerGenerated] private static string <.ctor>b__0() { string CS$1$0000; CS$1$0000 = CS$1$0000.CheckNull(); Label_0009: return CS$1$0000; } private string CheckNull() { string CS$1$0000; CS$1$0000 = "Am I null? " + ((bool) (this == null)); Label_0017: return CS$1$0000; } }
The CompilerGenerated method doesn't make sense; if you look at the IL (below), it's calling the method on a null string (!).
.locals init ( [0] string CS$1$0000) L_0000: ldloc.0 L_0001: call instance string CompilerBug.Program/Derived::CheckNull() L_0006: stloc.0 L_0007: br.s L_0009 L_0009: ldloc.0 L_000a: ret
In Release mode, the local variable is optimized away, so it tries to push a non-existant variable on to the stack.
L_0000: ldloc.0 L_0001: call instance string CompilerBug.Program/Derived::CheckNull() L_0006: ret
(Reflector crashes when turning it into C#)
EDIT: Does anyone (Eric Lippert?) know why the compiler emits the ldloc
?
I have had that! (and got proof too)
This isn't a "bug". This is you abusing the type system. You are never supposed to pass a reference to the current instance (this
) to anyone within a constructor.
I could create a similar "bug" by calling a virtual method within the base class constructor as well.
Just because you can do something bad doesn't mean its a bug when you get bit by it.
I could be wrong, but I'm pretty sure if your object is null
there's never going to be a scenario where this
applies.
For instance, how would you call CheckNull
?
Derived derived = null; Console.WriteLine(derived.CheckNull()); // this should throw a NullReferenceException
Not sure if this is what you are looking for
public static T CheckForNull<T>(object primary, T Default) { try { if (primary != null && !(primary is DBNull)) return (T)Convert.ChangeType(primary, typeof(T)); else if (Default.GetType() == typeof(T)) return Default; } catch (Exception e) { throw new Exception("C:CFN.1 - " + e.Message + "Unexpected object type of " + primary.GetType().ToString() + " instead of " + typeof(T).ToString()); } return default(T); }
example: UserID = CheckForNull(Request.QueryString["UserID"], 147);
来源:https://stackoverflow.com/questions/1600662/this-null-in-c