9

Kodersでこのコードを見つけました：

private ServiceProvider SiteServiceProvider
{
    get
    {
        if (serviceProvider == null)
        {
            serviceProvider = new ServiceProvider(site as VSOLE.IServiceProvider);
            Debug.Assert(serviceProvider != null, "Unable to get ServiceProvider from site object.");
        }
        return serviceProvider;
    }
}

疑問に思っていますが、トリガーできる方法はありますか？Debug.Assert(serviceProvider != null私はnew、例外によってのみ中止できるという印象を受けています。その場合、アサートに到達することはありません。

4

3 に答える 3

12

ServiceProvider が !=/== 演算子をオーバーライドする可能性があるため、無効な状態の場合、null との比較で true が返されます。

とにかく奇妙に見えます。

于 2008-12-16T13:23:28.210 に答える
7

それがファクトリメソッドである場合、「nullのテスト」パターンがもっと期待されます-つまり

SomeType provider = SomeFactory.CreateProvider();
if(provider == null) // damn!! no factory implementation loaded...
{ etc }

知っておく価値のあるケースがもう 1 つありますが、ここでは当てはまりません (作成している型がわかっているため)... Nullable<T>; これは主にジェネリックの問題です。

static void Test<T>() where T : new()
{
    T x = new T();
    if (x == null) Console.WriteLine("wtf?");
}
static void Main()
{
    Test<int?>();
}

これについては、こちらで詳しく説明しています。

于 2008-12-16T13:30:54.607 に答える
3

同意します。通常の != 演算子 (Object から継承) が使用されている場合、これは決して起こりません。コンストラクターは常にオブジェクト参照を返します。指摘したように、コンストラクターで例外がスローされた場合、実行ポイントはプロパティを完全に離れます。

このコードの意図を確認します。もちろん、コンストラクターは、構築されたオブジェクトを一貫性のない状態のままにしておく可能性があり、おそらくそれをテストする必要がありました。

ServiceProvider クラスが System.IServiceProvider を実装している場合は、GetService() が null を返さないことを確認する必要があります。

于 2008-12-16T13:34:12.993 に答える