12

.net 3.5 で asp.net Web アプリを作成していますが、Try Catch finally ブロックを使用する場合と使用しない場合を知りたいですか? 特に、私の try catch の大部分は、ストアド プロシージャの実行と、テキスト フィールドまたはグリッドビューへの入力にラップされていますか? ストアド プロシージャを実行し、データ表示コントロールを設定するときに、Try Catch EVERYTIMEを使用しますか?

私のコードブロックは通常次のようになります。

    protected void AddNewRecord()
    {
        try
        {
           //execute stored proc
           // populate grid view controls or textboxes
        }
        catch (Exception ex)
        {
           //display a messagebox to user that an error has occured
           //return
        }
        finally
        { }
   }
4

7 に答える 7

11

答えは「場合による」です。

try{...} catch {...}問題が発生した場合に (トランザクションを使用して) 最後の良好な状態にロールバックできるように、あらゆるアトミック操作を使用することをお勧めします。これは、1 つまたは複数のストアド プロシージャである可能性があります。アプリケーションによって異なります。

例外をトラップする場合は、キャッチする例外を明示してください。「すべてをキャッチ」例外処理として知られているcatch (Exception ex)またはを使用する必要はありませんが、代わりに (たとえば) のような特定の catch ステートメントを使用する必要があります。catch()catch (IndexOutOfRangeException ex)

ただし、例外を処理できない場合、またはクリーンアップするためにできることが何もない場合は、例外をトラップしないでください。

于 2010-07-06T12:57:51.963 に答える
4

try catchcatch ブロックで例外を処理する場合にのみ、 を使用してください。ハンドルとは、エラーをログに記録し、エラーのために別のパスを選択することなどです。単に再スローするだけの場合は、キャッチを試しても意味がありません。

于 2010-07-06T13:00:14.053 に答える
1

他の人が言ったように、それは依存します。私は次の 2 つの状況で try/catch/finally ブロックを使用する傾向があります。

  • 単に再スローする以外の方法で例外を処理する必要があります。

  • finallyブロック内のいくつかのリソースをクリーンアップする必要があります。

これら 2 つの状況以外では、発生する可能性のあるすべての例外を呼び出し元のコードで処理できるようにします。

于 2010-07-06T13:06:34.877 に答える
1

他の人が言ったことに加えて、これを避けるようにしてください：

    try
    {
        throw new ApplicationException("Fake sql ex");
    }
    //catch and do nothing.  swallowing exceptions
    catch(Exception){ }
于 2010-07-06T13:08:08.003 に答える
0

Exceptionストアド プロシージャに何を期待していますか? pokemon 例外処理を使用せず、アプリケーションが何をすることが期待されているかを正確に知っている場合、キャッチしたい特定の Exception に適合しないものはすべてApplicationオブジェクトによってキャッチされます。

catch {}つまり、 orを使用せずcatch (Exception)、特殊な例外処理を行います。

catch(SqlException e)
{
   // Log stacktrace and show a friendly error to your user
}

Application.Errorイベントは、予期しない動作をキャッチする必要がある場所であり、顧客が「フィールドに何も表示されない」と言って戻ってくるよりも簡単に追跡できます。

于 2010-07-06T13:17:45.743 に答える
0

ほとんどの場合、例外をキャッチするべきではありません。例外をキャッチすることが理にかなっている場所もあります。

その特定の例外から回復できるとき。ログに記録したり報告したりする必要がある場合 (たとえば、ユーザーに) -- 通常はコードの最上位レベルにあります。コードの呼び出し元が例外を処理できない場合、それらを他のエラー形式に変換する必要があります。

また、using ブロック ステートメントを使用して、IDisposable オブジェクトで実際に Dispose を呼び出すことができます。これにより、try...finally の必要がなくなります。

于 2010-07-06T12:59:12.473 に答える
0

特定の例外が発生したときに実行し続ける必要がある最も内側のループ内で「try catch」を使用します。10,000 回実行されるループがあり、たとえば 10 回目の繰り返しで例外が発生し、他の 9,990 回には影響しない場合は、例外をキャッチしてループを続行させると便利な場合があることに注意してください。一方、例外が、ループの 11 回目、12 回目、13 回目なども失敗することを示唆する障害を示している場合は、操作を再試行し続けるよりも、例外にループを強制終了させる方がはるかに高速です。それはうまくいきません。

于 2010-07-06T15:58:57.893 に答える