2010-12-20 11 views
1

私は、メモリ不足のエラーを処理するための良いプラクティスは何ですか?メモリ不足エラーを処理するためのベストプラクティスは何ですか?

void SomeTask() 
{ 
    try 
    { 
     SomeObj obj = new SomeObj(); 
    } 
    catch(std::bad_alloc&) 
    { 
     // What should be done here? 
    } 


    // ... more code ... 
} 

プログラムが不確定な状態で実行されている可能性があるため、私は黙って戻り値が間違っているように感じます。だから、ここで何が起こるべきか、私はプログラムをクラッシュさせなければならないのか、それとも良い選択肢があるのだろうか?このプログラムはサービスとして実行されるので、エラーメッセージをポップアップすることはできません。私はそれを行うために十分なメモリが残っている場合、何かをログに記録することが可能かもしれないと思います。しかし、私はちょうど、このような状況で何をすべきだと思いますか?

ありがとうございました。

+6

まず、nullをテストしないでください。 'std :: bad_alloc'をキャッチします。 –

+0

よろしくお願いします。 –

+3

修正できない限り、secondはbad_allocを捕まえません。割り当てのポイントの近くにはほとんどどこにもありません。これがメインイベントループによって開始された何らかのサービスの場合は、サービスが終了してイベントループに戻ることができます。これが通常のアプリケーションフローの一部である場合、通常の結果は、スローによってアプリケーションが終了するようにすることです。 main()のすべての例外をキャッチしてログに記録し、例外を再現します。 –

答えて

5

サービスなので、システムメッセージログにエラーが書き込まれます。 Windowsでは、Windows Event Log APIを使用できます。あなたのドキュメントで他に指定していない限り、これはおそらくsysadminが失敗報告を見ることが期待される場所です。

また、ほとんどのC++コンパイラでは、std :: bad_alloc()は失敗したヒープ割り当てにnull戻り値を置き換えました。

-PaulH

+1

'std :: bad_alloc'を取得した場合、失敗する可能性は低くなりません。 – wilhelmtell

2

それがサービスとして実行されるため、それがクラッシュしてみましょうが、それはエラー状態をログに記録し、その後中止または自己終端することにより、第1制御された方法でそうさせるのがベストです。サービス制御マネージャーは、制御を中止したときにサービスを再開するように構成することができます。

可能であれば、制御されたダンプを強制することで、問題の原因を突き止めることができます。

あなたの本能は正しいですか?それ以外の処理は何ですか?メモリ不足状態になると、健康状態に戻ることはありません。 RIPプロセス。

+0

"決して"強すぎるかもしれません。 OOM状態から復旧できるケースがあります。しかし、一般的なケースでは、あなたが正しいです、それを終了させる以外に何もすることはできません。 – jalf

+0

あなたは正しいです、私は "それは非常に健康ではない"状態に戻る可能性があります使用することができます。しかし、終了する前にダンピングの利点は巨大です。 –

2

最初にすべきことは、より多くのメモリを解放することです。オブジェクトを定期的にスクラブする必要がある場合は、今すぐに実行する必要があります。すべてがうまくいけば、あなたは走り続けることができるかもしれません。

これに失敗すると、ディスクに保存する必要があるものをすべて保存して終了するようにしてください。これに余分なメモリが必要な場合は、起動時に先読みしてください。走り続けることは不可能なので、ただ死ぬべきです(abortまたは例外を再現してください)。

関連する問題