回答:
クラッシュを回避するようなOOMは回避します。
一度に大量の作業を行う（および大量のメモリを割り当てる）ことは避けてください。ディスク上にデータを保持し、OSのディスクキャッシュを信頼し、メモリマップされたIOを可能な限り使用し、一度にデータのごく一部のみを操作します。大量のデータをオンラインにする必要がある場合（低レイテンシで提供される）、すべての大規模な検索エンジン企業が行うように、複数のマシンのメモリにそれらを保持します。またはSSDを購入します。
この質問に答えるほとんどの人はおそらくmallocが0を返すことは非常に現実的な可能性がある組み込みシステムで働いたことはないでしょう。私が現在取り組んでいるシステムでは、合計で4.25KバイトのRAM（つまり、4352バイト）があります。スタックに64バイトを割り当てていますが、現在1600バイトのヒープがあります。ちょうど昨日、メモリの割り当てと解放を追跡できるように、ヒープウォークルーチンをデバッグしていました。ヒープウォークは、静的に割り当てられた小さな（30バイト）バッファーを使用して、シリアルポートに出力します。リリース版では無効になります。
これは消費者向け製品であるため、製品がリリースされたらメモリ不足にならないようにしてください。開発中だと思います。いずれにせよ、私にできることは、スピーカーを数回鳴らして強制的に再起動することです。
正直に言うと、これまでに行ったすべてのプロジェクト（まだどこでも作業していないことを念頭に置いてください）では、それが発生する可能性があるとは考えていません。
さらに、OOMを処理するには、リソースを事前に割り当てて、エラーメッセージを表示したり、すべてを保存したりする必要があります。
最近では、ピーナッツよりもメモリのコストが低く、頻繁に発生するはずのないものだと感じています。保護されたメモリの黎明期とそれ以前では、おそらくそれが問題でしたが、今は？私が今まで見た唯一のOOMエラーは、バグのあるコードによるものでした。
とにかく、mallocの戻りコードをチェックしても、通常は無意味です。
最新のオペレーティングシステムはメモリをオーバーコミットします。実際に利用可能なメモリよりも多くのメモリをプロセスに提供します。プロセスに付与されるメモリは仮想であり、すべて1つのゼロ化されたページにマップされます。
メモリに書き込むまでは、物理的で一意のページがプロセスに割り当てられます。この割り当てが失敗した場合、カーネルはメモリを見つけようとしてプロセス（おそらくあなたのもの）を終了します。その時点では、これ以上できることはありません。
組み込みシステム、リアルタイムシステム、または障害が命を落とすほどの重大なシステム、または数十億ドルに及ぶシステムを対象に開発を行っている場合を除き、メモリ不足の状態を心配することは、おそらく経済的に価値がありません。
ほとんどの場合、新しいオブジェクトを作成したり、何かを実行するタスクを実行したりするためのメモリがないため、とにかくメモリ不足のときにできることはほとんどありません。OOMを処理するアプリのコストと、それによって得られるメリットを比較検討する必要があります。
私はいつもエラーをチェックします。何かがエラー状態を返した場合は、プログラムで処理する必要があります。「メモリ不足です、行かなきゃ！」というメッセージであっても、「アクセス違反」「コアダンプ」などなんでもない。1つは処理するエラー状態で、もう1つはバグです。そして、ユーザーも同様にそれを認識します。
特定のケースでは、オペレーションをロールバックして、失敗したポイントに到達するまで割り当てたリソースを解放し、エラーを報告して、実行を継続することができます（アプリケーションを終了しようとしているときに、すぐに終了するオプション）。このようにして、ユーザーは何をするかを決定したり、ファイルをいじったり、ファイルを閉じたりするなどして、メモリを解放することができます。もちろん、状況にどう対処できるかは、プログラムに大きく依存しますインタラクティブである必要があるのは、おそらくエラーをログに記録して終了するか続行するだけです。