如果你有扩展方法:

public static bool? ToBoolean(this string s)
{
    bool result;

    if (bool.TryParse(s, out result))
        return result;
    else
        return null;
}

这段代码:

string nullStr = null;
var res = nullStr.ToBoolean();

这不会抛出异常，因为它是一个扩展方法(实际上是HelperClass.ToBoolean(null))，而不是一个实例方法。这可能会令人困惑。

我来派对晚了一点，但我有三四五

If you poll InvokeRequired on a control that hasn't been loaded/shown, it will say false - and blow up in your face if you try to change it from another thread (the solution is to reference this.Handle in the creator of the control). Another one which tripped me up is that given an assembly with: enum MyEnum { Red, Blue, } if you calculate MyEnum.Red.ToString() in another assembly, and in between times someone has recompiled your enum to: enum MyEnum { Black, Red, Blue, } at runtime, you will get "Black". I had a shared assembly with some handy constants in. My predecessor had left a load of ugly-looking get-only properties, I thought I'd get rid of the clutter and just use public const. I was more than a little surprised when VS compiled them to their values, and not references. If you implement a new method of an interface from another assembly, but you rebuild referencing the old version of that assembly, you get a TypeLoadException (no implementation of 'NewMethod'), even though you have implemented it (see here). Dictionary<,>: "The order in which the items are returned is undefined". This is horrible, because it can bite you sometimes, but work others, and if you've just blindly assumed that Dictionary is going to play nice ("why shouldn't it? I thought, List does"), you really have to have your nose in it before you finally start to question your assumption.

我想我之前向您展示过这个，但我喜欢这里的乐趣——这需要一些调试才能跟踪!(原来的代码显然更加复杂和微妙……)

    static void Foo<T>() where T : new()
    {
        T t = new T();
        Console.WriteLine(t.ToString()); // works fine
        Console.WriteLine(t.GetHashCode()); // works fine
        Console.WriteLine(t.Equals(t)); // works fine

        // so it looks like an object and smells like an object...

        // but this throws a NullReferenceException...
        Console.WriteLine(t.GetType());
    }

那么T是什么?

答:任何可空<T> -如int?。所有的方法都被重写，除了GetType()不能;因此它被强制转换为object(因此为null)来调用object. gettype()…哪个调用null;-p

更新:情节变得越来越复杂……Ayende Rahien在他的博客上提出了类似的挑战，但使用了where T: class, new():

private static void Main() {
    CanThisHappen<MyFunnyType>();
}

public static void CanThisHappen<T>() where T : class, new() {
    var instance = new T(); // new() on a ref-type; should be non-null, then
    Debug.Assert(instance != null, "How did we break the CLR?");
}

但它是可以被打败的!使用与远程处理一样的间接方式;警告-以下是纯粹的邪恶:

class MyFunnyProxyAttribute : ProxyAttribute {
    public override MarshalByRefObject CreateInstance(Type serverType) {
        return null;
    }
}
[MyFunnyProxy]
class MyFunnyType : ContextBoundObject { }

在此之后，new()调用被重定向到代理(MyFunnyProxyAttribute)，该代理返回null。现在去洗眼睛!

以下是我的一些建议:

当调用实例方法而不抛出NullReferenceException时，此值可以为null 不必为枚举定义默认枚举值

首先简单一点: enum NoZero ｛ Number = 1 }

        public bool ReturnsFalse()
        {
            //The default value is not defined!
            return Enum.IsDefined(typeof (NoZero), default(NoZero));
        }

下面的代码实际上可以打印真!

 internal sealed class Strange
{
    public void Foo()
    {
        Console.WriteLine(this == null);
    }
}

一段简单的客户端代码将导致这样的结果 HelloDelegate(奇怪的条);

public class Program
{
    [STAThread()]
    public static void Main(string[] args)
    {
        Strange bar = null;
        var hello = new DynamicMethod("ThisIsNull",
            typeof(void), new[] { typeof(Strange) },
         typeof(Strange).Module);
        ILGenerator il = hello.GetILGenerator(256);
        il.Emit(OpCodes.Ldarg_0);
        var foo = typeof(Strange).GetMethod("Foo");
        il.Emit(OpCodes.Call, foo);
        il.Emit(OpCodes.Ret);
        var print = (HelloDelegate)hello.CreateDelegate(typeof(HelloDelegate));
        print(bar);
        Console.ReadLine();
    }
}

这在大多数语言中都是正确的，只要调用实例方法时不使用对象的状态。只有在访问对象的状态时才解除引用

想想这个奇怪的例子:

public interface MyInterface {
  void Method();
}
public class Base {
  public void Method() { }
}
public class Derived : Base, MyInterface { }

如果在同一个程序集中声明Base和Derived，编译器将使Base::方法为虚拟且密封(在CIL中)，即使Base没有实现接口。

如果Base和Derived在不同的程序集中，编译Derived程序集时，编译器不会更改其他程序集，因此它将在Derived中引入一个成员，该成员将是MyInterface::Method的显式实现，它只会将调用委托给Base::Method。

编译器必须这样做，以支持与接口有关的多态分派，即它必须使该方法为虚拟。

今天刚发现一件小玩意儿

public class Base
{
   public virtual void Initialize(dynamic stuff) { 
   //...
   }
}
public class Derived:Base
{
   public override void Initialize(dynamic stuff) {
   base.Initialize(stuff);
   //...
   }
}

这会引发编译错误。

对方法'Initialize'的调用需要动态分派，但不能这样做，因为它是基本访问表达式的一部分。考虑强制转换动态参数或取消基本访问。

如果我写底。初始化(stuff as object);它工作得很完美，但这似乎是一个“神奇的词”，因为它的功能完全相同，一切仍然是动态的……