未処理の例外を処理する方法は？（アプリケーションを終了するか、生き続けるか）

デスクトップアプリケーションで未処理の例外が発生した場合のベストプラクティスは何ですか？

ユーザーがサポートに連絡できるように、ユーザーにメッセージを表示しようと考えていました。ユーザーにアプリケーションを再起動することをお勧めしますが、強制することはしません。ここで説明しているものと同様：ux.stackexchange.com-予期しないアプリケーションエラーを処理する最良の方法は何ですか？

プロジェクトは.NET WPFアプリケーションであるため、説明されている提案は次のようになります（これは簡略化された例です。ユーザーが[詳細の表示]をクリックして、エラーを簡単に報告してください）：

public partial class App : Application
{
    public App()
    {
        DispatcherUnhandledException += OnDispatcherUnhandledException;
    }

    private void OnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
    {
        LogError(e.Exception);
        MessageBoxResult result = MessageBox.Show(
             $"Please help us fix it and contact support@example.com. Exception details: {e.Exception}" +
                        "We recommend to restart the application. " +
                        "Do you want to stop the application now? (Warning: Unsaved data gets lost).", 
            "Unexpected error occured.", MessageBoxButton.YesNo);

        // Setting 'Handled' to 'true' will prevent the application from terminating.
        e.Handled = result == MessageBoxResult.No;
    }

    private void LogError(Exception ex)
    {
        // Log to a log file...
    }
}

実装（ViewModelsのコマンドまたは外部イベントのイベントハンドラー）では、特定の外因性例外のみをキャッチし、他のすべての例外（ボーンヘッドおよび未知の例外）を上記の「最後のリゾートハンドラー」までバブルさせます。骨抜きと外因性の例外の定義については、次を参照してください：Eric Lippert-Vexing exceptions

アプリケーションを終了するかどうかをユーザーに決定させるのは理にかなっていますか？ アプリケーションが終了すると、一貫性のない状態になります...一方、ユーザーは、保存されていないデータを失ったり、アプリケーションが再起動されるまで、開始された外部プロセスを停止できなくなります。

または、作成しているアプリケーションのタイプに応じて、未処理の例外でアプリケーションを終了する必要があるかどうかは決定されますか？コードの完全版、第2版で説明されているように、「堅牢性」と「正確性」のトレードオフにすぎませんか

私たちが話しているアプリケーションの種類を説明するために、アプリケーションは主に化学実験装置を制御し、測定結果をユーザーに表示するために使用されます。そのために、WPFアプリケーションはいくつかのサービス（ローカルおよびリモートサービス）と通信します。WPFアプリケーションは、機器と直接通信しません。

とにかく、電源障害やシステム全体をクラッシュさせる別のバックグラウンドプロセスなど、未処理の例外以外の理由でプログラムが終了することを期待する必要があります。そのため、アプリケーションを終了して再起動することをお勧めしますが、そのような再起動の結果を緩和し、データ損失の可能性を最小限に抑えるためのいくつかの対策を講じることをお勧めします。

以下のポイントの分析から始めます。

• プログラムが終了した場合、実際にどれだけのデータが失われる可能性がありますか？

• ユーザーにとってこのような損失はどれほど深刻ですか？失われたデータを5分未満で再構築できますか、それとも1日分の作業を失うことについて話しているのですか

• 「中間バックアップ」戦略を実装するのにどれだけの労力がかかりますか？コメントで書いたように、通常の保存操作では「ユーザーが変更理由を入力する必要がある」ため、これを除外しないでください。プログラムが自動的にクラッシュした後にリロードされる可能性がある一時ファイルまたは状態のようなものを考えてください。多くの種類の生産性ソフトウェアがこれを行います（たとえば、MS OfficeとLibreOfficeの両方に「自動保存」機能とクラッシュリカバリがあります）。

• データが間違っているか破損している場合、ユーザーはこれを簡単に見ることができますか（プログラムの再起動後）。はいの場合、ユーザーにデータを保存して（破損する可能性はわずかですが）、再起動を強制し、データをリロードして、データが正常かどうかをユーザーに確認させるオプションを提供できます。古いバージョンが破損しないように、定期的に保存された最後のバージョンを上書きしないようにしてください（代わりに一時的な場所/ファイルに書き込みます）。

このような「中間バックアップ」戦略が賢明なオプションである場合、最終的にはアプリケーションとそのアーキテクチャ、および関連するデータの性質と構造に依存します。しかし、ユーザーが10分未満の作業を失い、そのようなクラッシュが1週間に1回、またはめったに起こらない場合は、おそらくこれにあまり投資しません。

開発しているアプリケーションにある程度依存しますが、一般的に、アプリケーションで未処理の例外が発生した場合は、終了する必要があると思います。

どうして？

アプリケーションの状態に自信が持てなくなるためです。

間違いなく、有用なメッセージをユーザーに提供しますが、最終的にはアプリケーションを終了する必要があります。

あなたのコンテキストを考えると、私は間違いなくアプリケーションを終了したいと思います。ラボで実行されているソフトウェアが破損した出力を生成することは望ましくありません。例外を処理することを考えていなかったため、例外がスローされた理由と何が起こっているのかわかりません。

これは化学実験室向けであり、アプリケーションが機器を直接制御するのではなく、他のサービスを介して制御することを考慮してください。

メッセージを表示した後、強制終了します。未処理の例外の後、アプリケーションは不明な状態になります。誤ったコマンドを送信する可能性があります。それは鼻の悪魔さえ呼び出すことができます。誤ったコマンドは、潜在的に高価な試薬を無駄や機器や人々に危険をもたらす可能性があります。

しかし、あなたは他の何かをすることができます：再起動後に正常に回復します。あなたのアプリケーションは、クラッシュしたときにそれらのバックグラウンドサービスをそれ自体でダウンさせないと仮定します。その場合、それらから簡単に状態を回復できます。または、さらに状態がある場合は、保存することを検討してください。データの原子性と整合性を備えたストレージ（SQLiteかもしれません）。

編集：

コメントで述べたように、あなたがコントロールするプロセスは、ユーザーが反応する時間がないほど十分に速い変更を必要とするかもしれません。その場合、正常な状態の回復に加えて、アプリのサイレント再起動を検討する必要があります。

プログラムのトップレベルでこの質問に一般的に答えようとするのは賢明なことではありません。

何らかの問題が発生し、アプリケーションのアーキテクチャのどの時点でもこのケースを考慮しなかった場合、アクションが安全であるかどうかについて一般化することはできません。

だから、いいえ、アプリケーションと開発者がそれが可能か賢明であるかを見つけるために必要なデューデリジェンスを実証していないので、ユーザーがアプリケーションが回復しようとするかどうかを選択できるようにすることは一般的に許容できる設計ではありません。

ただし、この種の障害回復を念頭に置いて設計されたロジックまたは動作の価値の高い部分がアプリケーションにあり、この場合はそれらを活用することが可能であれば、どうしてもそうする-その場合、リカバリを試行するかどうかを確認するようにユーザーにプロンプ​​トを表示したり、単に呼び出して終了したり、最初からやり直したりすることができます。

この種の回復は一般にすべての（またはほとんどの）プログラムに必要または推奨されるわけではありませんが、この程度の運用上の整合性が必要なプログラムで作業している場合、この種のユーザーにプロンプ​​トを表示するのは正気です。

特別な障害回復ロジックが必要な場合-いいえ、これを実行しないでください。あなたは文字通り何が起こるかわからない、もしあなたがそうすれば、あなたは例外をさらに見つけてそれを処理しただろう。

「例外的な例外」、つまりあなたが予見していない例外の問題は、プログラムがどの状態にあるかわからないことです。たとえば、ユーザーのデータを保存しようとすると、実際にはさらに多くのデータが破壊されます。

そのため、アプリケーションを終了する必要があります。

George CandeaとArmando FoxによるCrash-only Softwareという非常に興味深いアイデアがあります。アイデアは、それを閉じる唯一の方法がクラッシュすることであり、それを開始する唯一の方法がクラッシュから回復することであるようにソフトウェアを設計する場合、ソフトウェアはより回復力があり、エラー回復コードパスはより徹底的にテストされ、実行されます。

一部のシステムは、正常なシャットダウン後よりもクラッシュ後の方が速く起動することに気付いた後、彼らはこのアイデアを思いつきました。

関係のない例ですが、クラッシュから回復する際の起動が速くなるだけでなく、起動時の操作性も向上する Firefoxの古いバージョンがあります。これらのバージョンでは、Firefoxを正常にシャットダウンすると、開いているタブがすべて閉じられ、1つの空のタブで起動します。一方、クラッシュから復旧する場合、クラッシュ時に開いていたタブを復元します。（そして、それが現在のブラウジングコンテキストを失うことなくFirefoxを閉じる唯一の方法でした。）それで、人々は何をしましたか？彼らはFirefoxを決して閉じず、常にpkill -KILL firefoxそれを編集しました。

Linux Weekly Newsには、Valerie Auroraによるクラッシュ専用ソフトウェアに関する素晴らしい記事があります。コメントも読む価値があります。たとえば、コメントの誰かが、これらのアイデアは新しいものではなく、実際には、Erlang / OTPベースのアプリケーションの設計原理とほぼ同等であると指摘しています。もちろん、ヴァレリーの10年後、元の記事の15年後の今日、これを見ると、現在のマイクロサービスの誇大広告が同じアイデアを再発明していることに気付くかもしれません。最新のクラウド規模のデータセンター設計も、より粗い粒度の例です。（どのコンピューターでも、システムに影響を与えることなくいつでもクラッシュする可能性があります。）

ただし、ソフトウェアをクラッシュさせるだけでは不十分です。それのために設計する必要があります。理想的には、ソフトウェアは小さな独立したコンポーネントに分割され、それぞれが独立してクラッシュする可能性があります。また、「クラッシュメカニズム」は、クラッシュするコンポーネントの外部にある必要があります。

ほとんどの例外を処理する適切な方法は、結果として破損状態にある可能性のあるオブジェクトを無効化し、無効化されたオブジェクトがそれを妨げない場合は実行を継続することです。たとえば、リソースを更新するための安全なパラダイムは次のとおりです。

acquire lock
try
  update guarded resource
if exception
  invalidate lock
else
  release lock
end try

保護されたリソースの更新中に予期しない例外が発生した場合、例外が良性であるかどうかに関係なく、リソースは破損状態であると推定され、ロックが無効になります。

残念ながら、IDisposable/ usingを介して実装されたリソースガードは、ブロックされたブロックが正常に終了したか異常に終了したかを知ることなく、保護されたブロックが終了するたびに解放されます。したがって、例外の後にいつ続行するかについて明確に定義された基準があるはずですが、それらがいつ適用されるかを伝える方法はありません。

すべてのiOSおよびMacOSアプリが従うアプローチを使用できます。キャッチされない例外は、アプリケーションをすぐに停止します。さらに、範囲外の配列や、新しいアプリケーションの算術オーバーフローなど、多くのエラーでも同じことが行われます。警告なし。

私の経験では、多くのユーザーは通知を受け取らず、アプリのアイコンをもう一度タップするだけです。

明らかに、このようなクラッシュが重大なデータ損失を引き起こさず、間違いなくコストのかかる間違いを引き起こさないことを確認する必要があります。ただし、「アプリはすぐにクラッシュします。わからない場合はサポートに電話してください」と言っても、誰も助けにはなりません。