7

メソッド (またはメソッド チェーン) を呼び出す際に null オブジェクトを処理するための最良のオプションを探しています。

if 条件でチェックするのが私たちの一般的な方法です:

if ( customObject != null ) {
    customObject.callMe();
}

これは、拡張メソッドを使用してさらに改善できます。

Program customObject = null;
if (customObject.NotNull()) {
    customObject.CallMe();
}

public static bool NotNull(this object o) {
    return o == null;
}

注意してください：私は通常無視します！私のプログラミングの練習から。したがって、私にとっては拡張メソッドが適していると言うのが賢明です。

ただし、メソッドチェーンが絡むと非常に扱いが複雑になります。

customObject.CallMe().CallMe2() ex...

がnullでない場合にのみ呼び出され、 null以外のオブジェクトを返す場合にのみCallMe呼び出されるように、C＃で処理できるとどのように考えていますか。customObjectCallMe2CallMe

もちろんIf条件や三項演算子も使えます。ただし、vNext、C#5.0 で提供できるものがあるかどうかを知りたいです。

4

6 に答える 6

15

今後の C# 6 (vNext) には?.演算子 (Null Conditional Operator) があり、ネストされたすべてのプロパティに対して null 参照チェックを簡単に連鎖させることができます。

この例は次のようになります。

int? first = customers?.[0].Orders?.Count();

これは、Visual Studio UserVoice サイトで要求された機能でした

追加 ？。演算子から C#

Roslyn の Codeplex サイトで、C# 6.0 のすべての新しい言語機能の状態を確認できます。

C# 6 言語機能のステータス

于 2014-09-01T00:10:20.973 に答える
4

現在、次の種類の拡張メソッドを記述できます。

public static class Extensions
{
    public static R IfNotNull<T, R>(this T @this, Func<T, R> @select) where T : class
    {
        return @this.IfNotNull(@select, () => default(R));
    }

    public static R IfNotNull<T, R>(this T @this, Func<T, R> @select, Func<R> @default) where T : class
    {
        return @this != null ? @select(@this) : @default();
    }

    public static void IfNotNull<T>(this T @this, Action<T> @action) where T : class
    {
        if (@this != null)
        {
            @action(@this);
        }
    }
}

次に、次のように呼び出します。

customObject 
    .IfNotNull(y => y.CallMe())
    .IfNotNull(y => y.CallMe2());
于 2014-09-01T00:56:53.390 に答える
0

C# 6 には?演算子があります。それ以外の場合は、モナド、特にMaybeモナド(たとえば、ここ、ここ、他の場所) を調べることができます。モナドを念頭に置いて設計されていない非関数型言語でモナドを使用する価値があるかどうかは別の問題です。

于 2014-09-01T00:27:34.180 に答える
0

人々はあなたがばかではないと仮定する答えを引き裂いているので、ここにあなたがばかであると仮定する答えがあります.

がいつcustomObject作成されたかを確認する必要がありました。これは、 null を取得した理由がわかる時点だからです。そのときにチェックしなかった場合、最善の策は、コードで例外をスローさせることです。明らかに必要なオブジェクトがなくても、完全に理にかなったことができることがまだある場合は、例外のキャッチでそれを修正できますが、おそらくそうではありません。

予期しない null の重要性を無視するすべてのメカニズムは、提案された null 伝播演算子の習慣的な乱用や、使用前にオブジェクトをチェックするすべての習慣など、以前に注意を払っていなかったことに失敗しているだけです。彼らは、大惨事への注意を最小限に抑える効果的な大惨事への対応を求めています。

オブジェクトが null であることで重要な情報を通知している場合、それはおそらく設計上の選択として不適切であり、null が導入されたときに、null をより使いやすい情報に変換する必要がありました。

オブジェクトが生成された直後ではなく、使用される直前にオブジェクトの予期しない null 性をテストすることは、実際には誰の助けにもなりません。これは、おそらく次のいずれかの方法で、責任を置き忘れたことを示すコードの匂いです。

  1. 十分な説明なしに意地悪なデザイン決定を下す人々に異議を唱えたくない
  2. 組み込んだものを自分でコントロールできているとは感じていないが、それをラップするのが面倒だ
  3. null が存在するはずがないと信じており、それらを無視しようとしているため、null に関するポリシーを検討していません。

あなたが示す、ヌルを食べて、それを分析せずに実行を続けるというポリシーは悪いものです。あなたがそれを維持するつもりなら、それが私の他の答えです. 代わりに、合理的なことを行う必要があります。

多くの職場では、空のcatchブロックをどこにでも配置することで、将来の作業を明確に文書化できます。だから何かをしている。しかし、それをそのままにしておくと、優れたコードに立つべきオプションは決してありません。このようなブロックは、コードブロックがよりローカルな方法で問題に対処する回避策を実装している場合でも、エラーの原因を修正するための将来の作業を作成する応答に例外をより合理的に変換します。

于 2014-09-01T16:02:33.953 に答える