Question

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#?

Was it helpful?

Solution

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.

OTHER TIPS

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)

alt text

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);

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top