特にサーバーコードで、「骨の折れた」例外をキャッチしないのはなぜですか？

私はかなりの数の場所で、いわゆる「骨頭のある」例外（コードのバグに起因するもの）が捕捉されないはずであることをすでに読んだため、混乱しています。代わりに、アプリケーションのクラッシュを許可する必要があります。

Vexing exceptions 、Eric Lippert著
Eliding Async and Await の下のコメント、Stephen Cleary著
以下の回答自己定義の例外を使用することは良い習慣ですか？ 、Draco18sはSEを信頼しなくなりました

上記の3人のうち少なくとも2人は権威者です。

びっくりです。特に、サーバー側のコードなど、一部の（重要な！）ユースケースでは、なぜこのような例外が最適化されていないのか、およびアプリケーションのクラッシュを許可する必要がある理由がわかりません。

私の知る限り、このような場合の一般的な解決策は、例外をキャッチし、HTTP 500をクライアントに返し、開発チームに緊急メールを送信する自動システムを用意して、問題を修正できるようにすることです。できるだけ早く-しないでくださいアプリケーションをクラッシュさせます（1つの要求は失敗する必要があります。ここで実行できることは何もありませんが、サービス全体を停止して他のすべてのユーザーを作成する理由）当社のウェブサイトを使用できませんか？ダウンタイムはコストがかかります！）。私は間違っていますか？

なぜ私が尋ねているのか-.netコアのブラウザベースのゲームである趣味のプロジェクトを終わらせようとしているのです。私の知る限り、多くの場合、フレームワークは私のために箱から出してEric LippertとStephen Clearyが推奨していない正確なことをしています！ -つまり、リクエストがスローされた場合、フレームワークは自動的に例外をキャッチし、サーバーのクラッシュを防ぎます。ただし、いくつかの場所では、フレームワークはこれを行いません。そのような場所では、私は自分のコードをtry {...} catch {...}でラップして、考えられるすべての「骨の折れる」例外をキャッチしています。

そのような場所の1つであるAFAIKは、バックグラウンドタスクです。たとえば、私は現在、数分ごとに期限切れの一時的な禁止をすべてクリアすることになっているバックグラウンドの禁止クリアサービスを実装しています。ここでは、すべてをキャッチするtryブロックのいくつかのレイヤーを使用しています。

try // prevent server from crashing if boneheaded exception occurs here
{
    var expiredBans = GetExpiredBans();
    foreach(var ban in expiredBans)
    {
        try // If removing one ban fails, eg because of a boneheaded problem, 
        {   // still try to remove other bans
            RemoveBan(ban);
        }
        catch
        {

        }
    }
}
catch
{

}

_{（はい、私のcatchブロックは現在空です-私はこれらの例外を無視することは受け入れられないことを承知しており、TODOリストにいくつかのロギングを永続的に追加しています）}

上記にリンクした記事を読んだ後、深刻な疑いなしにこれを続けることはできません...私は足で自分を撃っていませんか？なぜ/なぜですか？

骨の折れる例外が決してキャッチされるべきではない場合、その理由は？

design-patternsweb-servicesexceptionsanti-patternsantibugging

2020/01/04gaazkam

次のような例外を処理する理由/目的を考慮する必要があります。

アプリケーションが有意義に続行できるように、何らかの修正または回復アクションを実行するため。これは、例外とその結果がよく理解されていることを意味します
ある種のクリーンアップを実行して、アプリケーションを一貫した状態に復元します。繰り返しますが、例外の結果は完全に理解する必要があります
ロギングおよびその後の分析のために例外に関する情報をキャプチャするには
例外によって直接報告される生のメッセージやコードではなく、適切なUIでユーザーフレンドリーでユーザーにとって意味のあるメッセージを発行するなど、適切に失敗する。これを行う場合、開発チームによる分析のために、より技術的な詳細をキャプチャすることが一般的に賢明です。

例外ハンドラーによって提供される有用な目的がない場合、ハンドラーはそこに存在してはならず、例外は「バブルアップ」することが許可されているはずです。

「ボーンヘッド」例外は、アプリケーションが最初にコーディングされたときに予期されなかった状態を意味します。予期しない例外については、原因を特定して適切な措置を講じられるように、可能な限り多くの詳細を記録する必要があります。これはプログラミングフレームワークによって自動的に行われます。もしそうなら、それらを明示的に処理したくないかもしれません。

2020/01/07Zenilogix