2012-11-29 6 views
9

暗黙の文字列演算子を持つ型があります。それは次のようになります。暗黙の演算子がnullを処理する必要がありますか?

public class Foo 
{ 
    readonly string _value; 

    Foo(string value) 
    { 
     _value = value; 
    } 

    public static implicit operator string(Foo foo) 
    { 
     return foo._value; 
    } 

    public static implicit operator Foo(string fooAsText) 
    { 
     return new Foo(fooAsText); 
    } 

} 

我々は暗黙の演算子に渡さインスタンスがnullたシナリオをちょうど持っていました。明らかに、我々はNullReferenceExceptionで終わった。

私はこれが十分だと思ったのですが、結局のところ、null型の文字列表現は何ですか?例外は有効であり、傍受/抑制/処理/無視しないようです。私の推論は、「誰かが私にヌルを与えられた、なぜヌルを返すべきなのか」という行に沿っていました。私は他の方法でこれをしない。それは前に文字列への変換今だから、

string s = foo == null ? null : foo;

しかし、それは動作しませんでした:私は何かのように、「私はちょうどそれを変換する前にnullをチェックしましょう、私が知っている」、と思いましたヌルとの比較もちろん、この比較はうまくいくでしょう:

Foo f = null; 
string s; 
if (f != null) 
{ 
    s = f; 
} 

...それはちょうど醜いです。

私はEssential C# 5 4th editionセクション(サファリの「ラフカットの本)を読んで、それは言う:

が暗黙の変換からの例外をスローすることはありません。

これがないスロー例外をやると言うが、それは私が例外を抑制しなければならない思って私の葉?解決

public static implicit operator string(Foo foo) 
{ 
    return foo == null ? null : foo._value; 
} 

問題:

行うには、最も明白なことは、法にジャンプし、それを変更することです。しかし、私は汚れているように感じる。 nullをチェックして潜在的なバグを隠しているような気がします。私は妄想/肛門/愚かなのですか?

+1

すべてがあなたのユースケースによって異なります。 'string'をnullにしますか? –

+1

良い点。理想的には、 'Foo'のヌルインスタンスに遭遇しないことを望みます。うーん...おそらくそれは構造体でなければなりません... –

+2

@SteveDunn:重要なことの一つ: 'NullReferenceException'は、コードを呼び出す際に例外を発生させるバグを常に*コード化しています*。だから単に 'foo'を' null'にチェックしないと、オペレータのバグです。 –

答えて

12

私がこのケースでお勧めするのは、失敗する可能性のある演算子が暗黙的ではなく明示的であることです。暗黙の変換の考え方は、それが広がっている(すなわち、決して失敗しない)ことである。一方、明示的な変換は、時には失敗することがあると理解される。

+1

ドキュメントでもこれが推奨されています。http://msdn.microsoft.com/en-us/library/z5z9kes2.aspx –

関連する問題