0

たとえば、ネットワーク障害などの致命的な例外が発生する可能性のあるメソッドを含むクラスを構築するとします。次のことを行うのがベスト プラクティスですか。

1) 例外をスローし、呼び出し元のプロシージャにトラップさせて処理させますか? 2) 呼び出し元のプロシージャがハンドラを追加したクラス イベントを発生させますか? 3) 例外を抑制し、意図した結果ではなくメソッドから False または Nothing を返しますか?

これが苛立たしいほど些細な質問である場合は、お詫び申し上げます。.NET は初めてです

4

3 に答える 3

0

私はむしろオプション1で行きたいです。

例外にできるだけ多くの情報を提供し、呼び出し元に例外を処理させます。これに加えて、呼び出し元が元のメッセージとスタック トレースを受信できるように、例外を再スローする (または最初にキャッチしない) ようにする必要もあります。

呼び出し元が知らないうちに、例外を飲み込むことはほとんどありません。

例外と例外処理から(C# プログラミング ガイド)

例外を処理できず、アプリケーションを既知の状態のままにしておく場合を除いて、例外をキャッチしないでください。System.Exception をキャッチした場合は、catch ブロックの最後で throw キーワードを使用して再スローします。

于 2012-10-25T03:52:10.090 に答える
0

コードに例外がある場合にクライアント エラーに戻るように WCF サービスを構築したときに、このことを考えました。

コードを調べて、発生する可能性のあるエラーをエラー コードとエラー メッセージに定義しました。クライアントに例外またはエラーが発生すると、メソッドは Int errorCode を返します。

クライアントは、私のサービスで別のメソッドを使用して、エラーを認識します。

コード例:

public string GetError(int error)
        {
            switch (error)
            {
                case 1:
                    _errorString = Constants.ERR_INVALID_INFORMATION;
                    break;
                case 2:
                    _errorString = Constants.ERR_DELETE_FAILED;
                    break;
                case 3:
                    _errorString = Constants.ERR_ADD_FAILED;
                    break;
                case 4:
                    _errorString = Constants.ERR_UPDATE_FAILED;
                    break;       
            }
            return _errorString;
        }
于 2012-10-26T01:49:16.003 に答える
0

いずれもある意味で人気のあるアプローチですが、何も返さないこと (黙って失敗することとも呼ばれます) は非常に危険です。

実際にクライアントコードを書いて、ライブラリをどのように使用するかを考えます。これは、例外とハンドラーのどちらが優れているかを示す良い指標になります。

于 2012-10-25T03:59:28.687 に答える