1

std::bad_allocこの関数で例外を処理する方法:

std::string GetString()
{
    std::string str;
    return str;
}

どの stl コンストラクターbad_allocでも をスローできるため、次のようにする必要があります。

std::string GetString()
{
    try
    {
        std::string str;
        return str;
    }
    catch(std::bad_alloc&)
    {
        return ""; // Constructs temporary std::string and returns. Could throw !
    }
}

繰り返しcatchますが、ブロックはまだ安全ではありません。

この関数の例外を証明したいだけです。

4

4 に答える 4

2

ただし、(私が思うに) 標準では保証されていませんが、ほとんどの (おそらくすべての)std::string実装は、空/短い文字列にメモリを割り当てません (@BoBTFish で言及されているように)。したがって、あなたのソリューションは「例外証明」と同じです。の代わりにデフォルトで構築された文字列を実際に返すことをお勧めします""。

ただし、自問すべき基本的な質問はbad_alloc、非常に大きな文字列を作成しようとしている可能性があるため、またはシステムが完全にメモリ不足であることを実際に示している場合に、予想されるものであるかどうかです。

数百万文字の文字列を作成しようとして割り当てが失敗した場合、より短い/空のエラー文字列を作成しても、おそらく別の例外はスローされず、エラー処理の適切な形式と見なすことができます。

プログラム/システムがメモリを完全に使い果たしたために失敗した場合、ローカルで処理することはできません (たとえば、他のメモリを解放することはできません)。直後に。したがって、空または短い文字列を返すことはおそらくまだ機能しますが、そもそも関数内でその例外をキャッチする理由はありません。

于 2015-03-13T12:00:05.093 に答える
0

原則として、例外の処理方法がわかっている場合を除き、例外をキャッチしないでください。

また、キャッチされていない例外が原因でクラッシュするプログラムは、例外を解決しようとした後にクラッシュするプログラムよりもデバッグが容易です。

あなたが示したケースでは、空の文字列を作成することが原因である場合、bad_alloc戻ることも""おそらく別の原因になりbad_allocます(別の空の文字列が暗黙的に作成されます)。

解決できる状況はほとんどありませんbad_alloc。たとえば、大量のデータをキャッシュしていることがわかっている場合は、キャッシュされたデータを解放して割り当てを再試行できます。

于 2015-03-13T12:57:23.993 に答える