1


0

ASP.NET MVC2-try / catch(throw?)ブロックの数と場所

私は例外処理ジャングル全体をスラッシングしている最中であり、必要なtry / catchブロックの数とそれらをどこに置くかを決定しようとしています。

私のコントローラーから

CreateInvitation(fromUser, toUser);

これは私のBLLメソッドを呼び出します

public static Invitation CreateInvitaton(User fromUser, User toUser)
{
    try
    {// see if toUser exists, then create the invitation}
    catch
    {// throw something, maybe?}
}

そのメソッドで実際に再スローする必要がありますか? 投げ直さなくても、スタックに戻りませんか?

コントローラーの呼び出しもtry / catchブロックでラップする必要がありますか、それとも冗長ですか?

たぶん、BLLメソッドのtry / catchブロックはまったく必要なく、コントローラーのtry / catchブロックだけが必要ですか?

私はここでかなり多くの可能な組み合わせを見ていますが、適切な組み合わせが何なのかわかりません。

ありがとう。

2 Answer


2


あなたの例で書かれているように、例外ハンドラは全く何もしていません。 (まあ、それは少し時間を無駄にしているが、それは何の役にも立たない)

それがあった:

try
{...}
catch
{
  // do something here.
   throw;
}

次に、try / catch&throwが必要になります。


1


*例外*の動作を示している場合にのみローカルで例外をキャッチし、ローカルで修正(またはコメント)できます。

例を見つけるのに十分難しい-ここに一つあります:私は_pessimistic lock_を必要とするいくつかのオブジェクトを持っています。 別の(バックグラウンド)アプリが読み取り中にWebアプリケーションからオブジェクトに書き込むと、災害が発生する可能性があるため、ロックが必要です。 非常にまれにしか発生しないため、これは本当に例外です。 さらに、事前に何もすることはできません(次の行が実行される直前にロックが取得された可能性があるため)。 ただし、オブジェクトが再び解放される可能性が高いことはわかっているため、数ミリ秒で再試行できます。 それでも、これらはすべてコントローラーではなくサービスクラスで発生します。

予期される条件(たとえば、無効な入力)に例外を使用しないでください。

また、メッセージのロギング(コントローラーで_not_を行う必要があります)およびエラーページの送信を除いて、Webアプリケーションのほとんどの例外を処理できないことに同意します。 最後に、例外をキャッチするときは、必ず正しく実行してください(特定の例外タイプをキャッチし、「throw ex;」ではなく「throw;」で逆戻りします)