8 
public class PageNotFoundException : HttpException
{
    public PageNotFoundException()
        : base(404, "HTTP/1.1 404 Not Found")
    {

    }
}

アイデアは、毎回これを入力するのではなく、

throw new HttpException(404, "HTTP/1.1 404 Not Found")

むしろ書きたい

throw new PageNotFoundException();

innerException を含めるためにオーバーロードを追加するつもりでしたが、これを try/catch ブロックで使用することはありません。

この良い習慣を検討しますか？
つまり、例外から継承し、ハードコードされた情報を base(...) に渡します。

4

3 に答える 3

7

実際の質問に固有のものになるように回答を書き直すことにしました。より広い意味では、これらのベストプラクティスが適用されるのは MVC アプリケーションだけではありません。

(1)答えなさい。これは良い習慣ではありません。HttpException を直接スローする代わりに、例外ビルダー メソッドを使用する必要があります。

public static void ThrowPageNotFoundException() {
    throw new HttpException((Int32)HttpStatusCode.NotFound, "HTTP/1.1 404 Not Found");
}

(2)する。例外ビルダー メソッドを使用します (例: 私が提供したコード)。これにより、独自の例外タイプを持つことによる余分なパフォーマンス コストを回避し、インライン化することができます。例外をスローするメンバーはインライン化されません。これは、コンビニエンス スローの適切な代替手段です。

(3)する。可能な限り基本クラス ライブラリの例外を使用し、必要な要件を満たす基本例外がまったくない場合にのみカスタム例外を作成します。カスタム例外を作成すると、より深い例外階層が追加され、必要のないときにデバッグが困難になり、パフォーマンスのオーバーヘッドが追加され、コード ベースがさらに肥大化します。

(4)しないでください。基本クラス System.Exception をスローします。代わりに、特定の例外タイプを使用してください。

(5)しないでください。便宜上、カスタム例外を作成します。例外は本質的にコストがかかるため、これはカスタム例外の適切な理由ではありません。

(6)しないでください。独自の例外タイプを持つためだけにカスタム例外を作成します。

(7)しないでください。呼び出しコードを変更することで回避できる例外をスローします。これは、実際の問題ではなく、API にユーザビリティ エラーがあることを示唆しています。

.NET 開発シリーズのフレームワーク デザイン ガイドラインを読んだことがある人なら誰でも、これらのプラクティスを知っているでしょうし、これらは非常に優れたプラクティスです。これらは、.NET フレームワークが構築されたまさにそのプラクティスであり、MVC も同様です。

于 2012-04-19T05:01:59.970 に答える
2

あなたが最初に例外をスローしたのであれば、はい - それは問題ありません。ただし、 をキャッチしHttpExceptionて代わりに をスローしようとするPageNotFoundException場合は、元の例外を InnerException として配置する必要があります。

于 2012-04-19T04:56:53.967 に答える
1

これは独自のコードを独自に使用するための優れた構成要素ですが、1 つの考慮事項は、他の開発者や新しい開発者とやり取りする場合に危険になる可能性がある慣例によるコーディングを促進する可能性があることです。

独自のライブラリで、404 HttpException をスローする必要がある場合は常に PageNotFoundException をスローすることに一貫性がある場合は、catch (PageNotFoundException). ただし、カスタム例外を持たない他のライブラリの使用を開始すると、他のコードによってスローされた 404 HttpExceptions を見逃すことになります。同様に、他の開発者が後日貢献する場合 (または将来的に独自の追加を行う場合)、PageNotFoundExceptions がほとんどの機能によってキャッチされているものであるという考慮事項が見逃され、新しいモジュールで新しい 404 HttpExceptions がスローされる可能性があります。 、同様にコピー/貼り付けされた呼び出しコードではキャッチされません。

基本的に、このような構成は、プロジェクトの作業に必要な順応時間を増加させ、このコストを最小限に抑える方法で処理する必要があります (まだ散らかっていない、見つけやすい中央の共有オブジェクト ライブラリで十分に見えるようにする)。 .

一方、本質的にファクトリ パターンの利点を探している場合は、HttpExceptions の生成を一元化することには確かに価値があります。それがあなたがそれから抜け出そうとしているのであれば、代わりにそれを使う価値があるかもしれません（throw ExceptionFactory.NewPageNotFound()）。

于 2012-04-19T05:01:36.353 に答える