7

aspx.csの未処理のエラーコードは、global.asaxのApplication_Errorハンドラーによってキャッチされます。
aspx.csで発生した未処理のエラーをログに記録するためにApplication_Errorハンドラーにいくつかのコードを記述しましたが
、ログ自体のコードも失敗して例外が生成された場合（I / Oまたはファイルシステムの問題が原因である可能性があります）
そのような例外をスローする必要があります？
私がそれを捨てた場合、どのイベントがそのような例外を受け取るべきですか？
または、「throw」構文を記述してもしなくても違いはありませんか？
コードは次のようにサンプリングします

protected void Application_Error(object sender, EventArgs e)
{
    try
    {
        // my codes to log exception to Database System here....
    }
    catch(Exception)
    {
        throw;  //Should I write "throw" syntax here ? 
    }
}
4

2 に答える 2

5

Application_Errorは、スレッド（現在リクエストを処理している）が中止される前に発生した例外をログに記録できる最後の場所です。

関数の終了後に自動的に例外をスローするため、例外をスローする必要はありません。

これがその合理的な実装です。

あなたの最大の関心事は、フェイルオーバーメカニズムが失敗した場合の対処方法だと思います。この場合、それはあなたのロギングです。これはコンピューターではより大きな問題ですが、連鎖フェイルオーバーメカニズムを構築することは、最終的にすべてが失敗する可能性があるため、一般に時間の無駄です（あなた自身の研究のための副次的な提案：すべてを可能な限りステートレスに保つようにしてください）。最善の策は、99.9％の確率で成功する最後の手段として、非常に信頼性の高いロギングメカニズムを用意することです。そのようなメカニズムを作成する方法については説明しません（自分で作成するのは良い考えではありません-とにかく独自のロガーを作成してください。ロギングのパフォーマンスが十分で邪魔にならないようにするための秘訣がたくさんあります）。全体的にはelmahを使用することをお勧めします、それはおそらく現在利用可能な最高のロギングフレームワークであり、あなたの目的に役立つでしょう。

発生する可能性のあるごくわずかなエラー（実際の状況では発生しない可能性が高い）については、私はそれらの上で眠りを失うことはありません。

于 2013-02-22T07:52:35.397 に答える
0
  • Server.GetLastException()ロギング後にスローしますか？それはその例外の性質と原因に依存します。特別な場所やポップアップで表示します
  • その例外をログに記録しようとして例外が発生した場合はどうなりますか？それなら間違いなくあなたはそれを飲み込みたいかもしれません
于 2013-02-22T06:31:32.540 に答える