2011-01-23 1 views
1

私はコントロールフローの質問があります。私の会社では、多くのboolメソッドを作成し、エラーがあった場合はfalseを返します。例:例外の対Cの "if"

public bool Foo(string path, string fileName, ref string error) 
{ 
    if (path == null) 
    { 
     error = "path is null"; 
     return false; 
    } 
    path += fileName; 
    return true; 
} 

ご覧のとおり、醜いです。私はそういう例外でそれを使いたい:

public voidFoo(string path, string fileName, ref string error) 
{ 
    if (path == null) 
    { 
     throw new SomeException("Path is null."); 
    } 
    path += fileName; 
    return true; 
} 

しかし私たちはオーバーヘッドについて心配しています。我々がすべき?

+1

何2番目の例で、醜い 'error'パラメータを削除することが本当に必要です。 –

+2

皆さん、本当に同じことを言うほど多くの回答が本当に必要ですか? –

+0

'path'が' void'を呼び出す前に 'null'でないことを保証すれば、オーバーヘッドがゼロになります。 – Lightman

答えて

3

例外がでない場合、がスローされた場合、try...catchのオーバーヘッドは無視できます。だから、親指のルールは次のとおりです。

  • 例外がそうスローされる場合(path == nullは、「サポート」のシナリオである場合、すなわち、)、戻り値を使用します。
  • 例外がである可能性は低い、つまりpath == nullが通常、関数を使用している開発者が間違っている場合にのみ発生しますが、例外を使用します。
1

どのように例外がこのオカレンスですか?例外を投げたりキャッチしたりすると、オーバーヘッドが発生し、一般的な使用方法では受け入れられない可能性があります。

フロー制御の例外を使用すると、パフォーマンスと理解の両方の理由から、目立たなくなります。例外が発生した場合は例外を使用します。パフォーマンスが重要な場合(そしてこれを測定する必要があります(premature optimisation being the root of all evilなど)、より最適な解決方法は戻り値を使用することです。

このようなシナリオの頭痛は、戻り値(通常はfalseまたはnull)を無視または誤って使用する可能性があることです。

2

フロー制御の形式として例外を使用しないでください。一般的に

は、例外をスローすると、はるかに高価な失敗値をチェックするよりも - 、path場合はfalseを返してはいけません、この場合には、常に存在することが予想され、空のpathは例外的な状況と例外があるべきスローされる。

メソッド設計の面では、戻り値をチェックするために呼び出しメソッドに頼るべきではありません。誰かがチェックを忘れると、falseが返されるとどうなりますか?例外は、明らかに何か悪いことが起こり、コードが実行を停止するため、この問題を解消します。

+0

あなたは、*規則的なフロー制御の形式として例外を使うべきではないということを意味します。 –

0

すべての書籍では、シグナルエラーの例外を使用する必要があると言われています。 ifを使用すると、ソース行の50%が返信エラーメッセージであるため、ソースを読み込んでバグレスかどうかを確認するのは難しいです。

多くのエラーが発生し、計算時間が非常に重要であることが予想されるタイムクリティカルなシナリオでのみ、戻り値を使用します。

0

私は例外が大好きです。私だけです。もちろん、実装する場所によって異なります。

たとえば、例外をスローするための非常に基本的なクラスをいくつか用意したいと思います。これらのクラスにはスローしないという責任がありません。

C#のすてきなことは、間違ってしまった場合にそれをさらに投げるので、すべての例外を捕まえる必要はないということです。そうすれば、多くのコードを節約できます。それ以外の場合ブール値はif false -> return false; if false -> return false;です。私はだと思うと、はオーバーヘッドになります。

もちろん、ある時点で例外をキャッチしなければなりませんが、それは実装者の選択肢です。あなたはもちろん、いくつかの巨大なキャッチブロックを望んでいないが、あなたがそれをキャッチしたい時点でのみ、あなたはそれをキャッチする必要があります。

私はそれに行きます。

1

リソースが利用できないなどの例外的な場合に例外を予約する必要があります。ディスクスペースまたはネットワーク接続。

フロー制御の例外を使用するのは間違っているだけで、正しく臭いはありません。

ブールリターンコードを使用するのも一方通行です。 refを介して返すのではなく、エラーの原因を説明するエラーオブジェクトを作成することもできます。

0

「偽」状態が例外的であるとみなされるかどうかによって異なります。言い換えれば、一般的には期待されていない。例えば

、あなたはそれがその作業を行うための方法がnullの場合、おそらくあなたは、例外ArgumentNullExceptionを投げるべきである、任意の意味をなさないメソッドにオブジェクトを渡す場合:

public void Foo(object obj) 
{ 
    if(obj == null) throw new ArgumentNullException("obj", "Object cannot be null."); 

    // 
}