答えは、エンジンの再始動能力とは何の関係もありません。
これは、独自のアプリケーション コードに関係しています。未処理の例外が発生した場合、アプリケーションの状態を理解する方法は本質的にありません。存在する場合、それは未処理の例外ではありません。また、自分の状態がわからない場合は、未処理の例外がこれ以上発生しないと確信できず、時間の経過とともにますます悪化する問題が発生する可能性が高くなります (予期しない状態がますます予期しない状態にカスケードするため)。 )。
これをサーバー上で実行されているコードと想像してください (node.js に固有のものではないため)。
start process
open two server sockets
process incoming requests
例外を処理せずに 2 番目のサーバー ソケットを開くことができなかった場合、アプリケーションが機能しない可能性があります。次の論理ステップでスレッドを再開しても、適切に機能しない可能性があります。エンジンを再起動しても 1 つのソケットを合理的に閉じることができず、2 番目の障害の原因を修正することはほとんどありません (ポートが既に使用されている可能性が最も高い)。正常に開いたソケットを閉じた場合は、再起動した方がよいアプリケーションを再度開くことができるようにします (または、アプリケーションをさらに悪化させます)。
これはおそらく明らかなケースですが、グラフィック アプリケーション (ゲームなど) を想像してみてください。
start process
load models
handle state (until closing)
draw screen
例外処理なしでモデルのロードに失敗した場合、描画中にエラーが増えるだけなので、プロセスは合理的に続行できません。
未処理の例外からの回復が妥当な場合があります。ほとんどのクライアント側の GUI フレームワークには、未処理の例外を登録する方法があります。これにより、Chrome の V8 リカバリに類似した、イベント スレッド (GUI スレッド) の再起動が可能になります。回復が保証されていないため危険です。未処理の例外の原因となったものは、まだメモリ内にあり、次の使用時に再び例外を引き起こす準備ができている可能性があります。ただし、よく開発されたアプリケーションは、そのような例外を考慮して、自分自身を完全に消去するのに十分なほど小さい可能性もあります。このようなハンドラー (未処理の例外の処理)の最適な使用法は、問題を修正できるように例外をログに記録することです。
別の言い方をすれば、アプリケーションでどこにも処理しなかった例外が発生したと想像してください。コードの次のパスで発生しないように修正するにはどうすればよいでしょうか? 安全に答えるには、原因を知っていることを意味します。つまり、A) 未処理であってはならず、B) 隔離されていることを意味します。
保証されている唯一の安全なリセットは、アプリケーションを再起動することを意味する最初から開始することです。