C++の例外は何のために使用しますか？

Question

おそらく例外的なのは、最も議論の余地のあるC++機能です。多くのチームincluding googleはそれらを使用しません。もちろん、それらを使用するかどうかは、状況によって異なります。たとえば、一部のゲームでは、メモリ不足でクラッシュする可能性がありますが、医療機器制御ソフトウェアではクラッシュする可能性があります。メモリ不足を除いて、ネットワークの中断、ファイルが見つからないなどの例外を使用するチームもあれば、例外と呼ばれるにはあまりにも一般的だと言う人もいます（他の人は言うかもしれませんが、 ？）

例外を使用しないとの決定は、潜在的に間違った引数に基づいており、例外セーフコードを記述することは困難です。いくつかの人々は、エラーコードを使用する代替手段を使用することは、少なくとも難しいコードにつながるため、議論が誤っていると言います。 David Abrahams clarifiesこのポイント。この質問に

、私が知って好奇心：

• 何例について、あなたは例外を使うのですか？
• アプリケーションのコンテキストとは何ですか？どうしてあなたは例外なく生きていけないのですか？
• 例外セーフコードをどのように書き込むことができますか？あなたがしなければならない投資の水準は？
• それは価値がありますか？

Answer 1

私は例外的な動作の例外をあまり頻繁に使用しません。デバッグがクラッシュするときは、ブレーク・オン・例外を頻繁に使用します。そのため、コードが例外を使用して通常起こるものを処理する場合、私は静かに発煙します。予期しない方法で物事が間違ってしまったときに使用してください。

受け入れ可能な例：あなたのコードが依存しているサーバーは利用できないため、サービスは意味のあるものを実行できません。

私はあなたのコードで悩まされているということを意味しています。つまり、ユーザーは100より大きい数値を関数の入力として入力し、数字は< = 100となります。

実際、ユーザー向けのアプリケーションで作業している場合、ユーザーは例外を生成するものを実行できないはずです。

これは非常にグレーの領域ですので、あなたが同意するならば、アップアップ/ダウンボートしてください。あなたが意見に同意しない場合は、理由を述べたコメントを投稿してください - 私は他のガイドライン/ルール/指標を聞いてみたいと思っています。

Answer 2

私の経験では、例外を「スマートに」回復するために例外処理を行うと、時間が経つにつれて、値に比べてオーバーヘッドが大きくなりすぎるほど複雑になります。代わりに私は検出のために例外を使用するというアプローチを採用しました。関数に例外がスローされ、その時点でログに記録することでより速くevを見つけることができます。問題。上位レベルでそれを捕捉するために例外を再現する階層を使用して私はそれを試みましたが、大きな利益を得ることなくコードを不必要に続行することが困難になることがわかりました。

Answer 3

多くの人がC++の例外を「何か例外的に起こった」ものとして扱っていますが、ほとんどの場合、アプリケーションレベルでのエラーチェックや検証を行うのに非常に便利ですライブラリ）

例は、私はむしろその後、目の中にも、

if(!MethodA()) 
{ 
    //retrieve and show error 
    return 1; 
} 
if(!MethodB() || !MethodC()) 
{ 
    //retrieve and show error 
    return 1; 
} 
//etc 

これは、少ないコードにつながる傾向があるの書き込み

try 
{ 
    MethodA(); 
    MethodB(); 
    //.. a whole lot of other methods crucial to succeed for app initialization 
} 
catch(const SomeException& e) 
{ 
    //show user the critical error contained in e 
    return 1; 
} 

を記述します。 eメソッド自体です。

Answer 4

私は、本当に例外的な状況では一般的にプロ例外ですが、「例外的」なものを決定する際には、ほとんどの場合よりも高いバーがあります。

これを難しくするのは、低レベルのコードで何が例外的なのかを判断する必要があるということですが、高レベルのコードだけが特定のエラーが例外的であるかどうかを知ることができます。たとえば、アイコンをロードする関数を考えてみましょう。それが失敗したら何をすべきですか？呼び出し元のコードだけが、障害が重大であるかどうか（プログラムはそのアイコンが続行する必要がある）かどうかを知っています（アイコンは装飾的です）。

実用的な問題は、優雅さを凌駕する傾向があります。失敗したコンストラクターは、R​​AIIが機能するために例外をスローする必要があります。一方、デストラクタは例外をスローするべきではありません。それから、例外を飛ばすことができないすべての障壁があります。たとえば、Windowsでは、OSコールバック（ウィンドウプロシージャのようなもの）から例外が伝播されるのは安全ではありません。マルチスレッドの場合、ワーカースレッドの1つで未処理の例外が発生すると、他のスレッドでハンドルを解放したり呼び出したりすることなく、プロセスが停止します。デバイスドライバとカーネルコードは、一般に、ページングの制約のためにC++スタイルの例外を使用することはできません。 COMは例外でうまくいきません。

Answer 5

私はそれらを使用して最終時間：

スロー "定数（適切な）エラーメッセージ"

深刻な状態に遭遇したとき。

複数回グローバル変数でデータをスタックしましたが、それはマルチスレッドコードを書き込む前です。私はそれを再考する必要があります（明らかに）。

もうこの手法をおすすめしません。

Answer 6

ほとんど誰もがコードを書くことで例外をスローすることができます。それらはすべて標準ライブラリの上にあります。それを考えると、私は「例外なし」というポリシーは良いものだとは思わない。

私は自分の例外を投げているコードを書いていません。なぜなら、投げが有用であるように間違っている可能性がある多くの事柄には直接対処しないからです。それを修正する明白な方法がないところで、何かが重大に間違っている場合は、スローするのは良い考えです。

例外がスローされた場合に、私が書いたことがうまくいくことを確認しようとしています。