0

私は最近、例外とその使用に関するベスト プラクティスを調べ始めました。

複数の引数を持つメソッドがあるとします。また、このメソッドには、パラメーターが少ない複数のオーバーロードがあり、デフォルト値を提供してメインの実装を呼び出します。

すべてのオーバーロードですべての引数を検証しますか?

public string Translate(string text)
{
    if (String.IsNullOrEmpty(text))
        throw new ArgumentNullException();

    return Translate(text, "english");
}

public string Translate(string text, string language)
{
    if (String.IsNullOrEmpty(text))
        throw new ArgumentNullException();

    // Do the rest of the work
    // ...
}

例外を再スローしますか?

public string Translate(string text)
{
    try
    {
        return Translate(text, "english");
    }
    catch
    {
        throw;
    }
}

public string Translate(string text, string language)
{
    if (String.IsNullOrEmpty(text))
        throw new ArgumentNullException();

    // Do the rest of the work
    // ...
}

または、オーバーロードで例外と try/catch ブロックを完全に削除する必要がありますか?

public string Translate(string text)
{
    return Translate(text, "english");
}

public string Translate(string text, string language)
{
    if (String.IsNullOrEmpty(text))
        throw new ArgumentNullException();

    // Do the rest of the work
    // ...
}

また、2 つのメソッドのドキュメントはどのようになりますか?

(C# XML コメントを使用します。特に<exception>要素を配置する場所。)

これはマイナーなトピックであることは認識していますが、この種の状況に遭遇するたびに不思議に思っています (実際にはかなり頻繁に発生します)。

4

4 に答える 4

3

オプションの引数はある意味でこれを解決します。その場合、メソッドは1つだけです。

public string Translate(string text, string language="english")

知っておくと便利なオプションの引数を持ついくつかの癖があります。

デフォルト値は、呼び出し元のコードに「焼き付け」られます。[...]これが引き起こす可能性のある問題は、パブリック定数を公開する場合と同じです。ライブラリのデフォルト値を変更しても、呼び出し元のコードを再コンパイルしない場合、呼び出し元のコードは引き続きメソッドを呼び出します。古いデフォルト値。これは、オプションのパラメーターを使用してAPIを設計するときに考慮する必要があることです。

于 2012-09-30T00:25:38.237 に答える
2

あなたが持っている3つのオプションの長所と短所のリストを作成して決定しましょう：

1. すべてのオーバーロードですべての引数を検証しますか?

長所 : 文字列が空かどうかを確認してから、例外をスローします。クラシックで良い。短所 : 例外がスローされた後に 2 番目の関数を呼び出しているため、文字列が空または null であるために例外が発生したことがわかっています。

だから私はこの考えを捨てます。

2. 例外を再スローしますか?

長所 : 1) これは私の個人的なお気に入りで、1 行ずつ進むとこうなります。2 番目の関数が呼び出され、そこで例外がスローされ、呼び出し元の関数の catch でキャッチされ、他のいくつかのジョブが実行されます。2) throw ex の代わりに throw キーワードを使用して、スタック トレースが損なわれていないことを確認します。3) 呼び出し側で例外を処理するのがベスト プラクティスです。

短所：短所を教えてください。何も見つかりません。

3. または、オーバーロードで例外と try/catch ブロックを完全に削除しますか?

長所 : 呼び出し関数で try catch を使用しません。正確には長所ではありませんが、ええと、一部のコードが削減されます。短所 : 適切な処理が行われておらず、ベスト プラクティスでは、呼び出し元の関数で例外を処理する必要があります。

2番目のオプションが最良のオプションだと思います。

また、本当に役立つリンクを共有したいと思います

ベスト プラクティス : コード プロジェクト リンク

私にお知らせください。

于 2012-09-30T00:57:19.917 に答える
0

実際、これは、静的ファクトリメソッドと呼ばれるもの（通常は名前が付けられgetInstance()ています）で最もよく行われると暗号で認識されている従来の問題であり、多くの質問を1か所にリファクタリングします。取得したすべての応答を処理しようとするとかなり厄介になりますが、何もしないことで例外を破棄することは決してありません。最終ユースケースのために大幅に単純化し、ログに何かを保持してフェイルファストするか、学生の設定。

于 2012-09-30T00:23:17.853 に答える