私はかつて、C ++プログラムが最終的にすべての例外をキャッチする必要があるとアドバイスされました。当時与えられた理由は、本質的に、例外がmain()奇妙なゾンビ状態に入る以外にバブルするプログラムです。これは数年前に話されましたが、振り返ってみると、観察された現象は、問題のプロジェクトからの非常に大きなコアダンプの長期にわたる生成によるものだと思います。
当時、これは奇妙だが説得力があるように思われた。C ++がすべての例外をキャッチしていないことをプログラマに「罰」するのはまったく無意味でしたが、私の前の証拠がこれを裏付けているようです。問題のプロジェクトでは、キャッチされていない例外をスローしたプログラムは奇妙なゾンビ状態に入ったように見えます-または、私が原因だと思うように、不要なコアダンプの中でのプロセスを停止するのは異常に困難です。
（なぜこれが当時より明白ではなかったのか疑問に思う人のために：プロジェクトは複数のプロセスから複数のファイルに大量の出力を生成し、あらゆる種類のaborted (core dumped)メッセージを事実上不明瞭にしました。プログラムの問題は通常、長期間のプログラムによって長時間にわたって多くのイベントから蓄積された状態に依存するのではなく、短期間のプログラムへの初期入力に依存していませんでした（< 1時間）したがって、デバッグビルドまたはデバッガーからの同じ入力でプログラムを再実行するだけで、より詳細な情報を取得することがより実用的でした。）
現在、例外を残すことを防ぐためだけに例外をキャッチすることの大きな利点または欠点があるかどうかはわかりませんmain()。
例外が過去に発生することを許可することで考えられる小さな利点main()は、結果がstd::exception::what()端末に出力されることです（少なくともLinuxでgccコンパイルされたプログラムの場合）。一方、これは代わりに、すべての例外をキャッチすることによって達成することは簡単ですから派生std::exceptionし、その結果を印刷std::exception::what()し、それが由来していない例外からのメッセージ印刷することが望ましいならstd::exception、それはその後、しなければならない出発前にキャッチされmain()、印刷するためにはメッセージ。
過去に例外が発生することを許可することで考えられるささいな欠点main()は、不要なコアダンプが生成される可能性があることです。大量のメモリを使用するプロセスの場合、これは非常に厄介であり、プログラムからコアダンプ動作を制御するにはOS固有の関数呼び出しが必要です。一方、コアダンプと終了が必要な場合は、代わりにを呼び出すstd::abort()ことでいつでも達成でき、コアダンプなしの終了はを呼び出すことでいつでも達成できますstd::exit()。
逸話的に、what(): ...クラッシュ時に広く配布されているプログラムによって出力されるデフォルトのメッセージを見たことはありません。
C ++例外が過去にバブルアップすることを許可または拒否する強力な議論は、もしあれば、何main()ですか？
編集：このサイトには、一般的な例外処理に関する質問がたくさんあります。私の質問は、特に処理できないC ++の例外に関するものでmain()、エラーメッセージが出力される可能性はありますが、すぐにエラーが表示されることがあります。