1

私はFailFastプリンシパルをフォローしています。コンストラクターのパラメーター引数をチェックするために、Assertionクラスを配置するのが良い習慣かどうか疑問に思っています。

例えば：

public static class Assertions
{
    public static void ParamterIsNotNull(object subject, string paramName = "")
    {
        if (subject == null) throw new ArgumentNullException(paramName, "Paramter cannot be null");
    }
}

および使用中：

public class Test
{
    public Test(object obj)
    {
        Assertions.ParamterIsNotNull(obj, "obj");
    }
}

これは、例外スローを別のクラスにオフロードするための良い方法ですか、それともコンストラクターで直接例外をスローする方が良いですか？

4

1 に答える 1

1

私が読んだこと (記事の最後) から、Martin は両方のことを行うのが良いと言っています - 意味のある例外を提供するファストフェイルと「スローフェイル」 - サポートに連絡して続行する能力をユーザーに与えます。例外に関係なく、正常に完了することができるタスク。

この場合、バッチ システムの例は非常に優れていました。バッチの 1 つのアイテムが失敗する可能性がありますが、ユーザーはおそらく残りのアイテムを処理する必要があるため、グローバル ハンドラー (グローバルハンドラーは次の項目に進むことを決定し、エラーを集計して、ユーザーに表示し、開発チームに通知を送信できるようにします)。

このようにして、両方が完了します。ユーザーの作業のほとんどが完了し、高速失敗の原則も同様に開始されます。

したがって、具体的なケースによって異なります。おそらく、クラスが他の操作に参加している場合、続行できるかどうかをより適切に判断できるグローバル クラス (またはそれを使用する呼び出し元クラス) が存在する可能性があります。

一方、クラスは、失敗した場合に呼び出し元のクラスが他の作業を実行できるかどうかを判断できないため、コンストラクターで例外をスローする必要があります。これは私が思うことです-はい:)。したがって、クラスがバッチのアイテムを表している場合、呼び出し元はおそらく例外をキャッチして続行します。ある種のエントリ ポイント クラスの場合 - 例外を適切に処理する (またはまったくスローしない) ことをお勧めします。ユーザーにエラー メッセージを表示し、詳細 (ログ) を提供して、開発チームが簡単に確認できるようにします。問題があった場所。

于 2011-12-04T07:17:50.900 に答える