そのようにフローを制御する手段として例外を使用することは避けます。代わりに、ループを からwhile (true)
などのメニュー クラスの状態をチェックするものに変更できますwhile (menu.isAlive())
。終了するには、単に alive 属性を false に設定するだけで、while ループが終了します。
現在のフローが回復できず、親フローに制御を戻す必要がある状況では、例外を使用する必要があります。そうは言っても、例外をそのように使用することを妨げるものは何もありませんが、個人的には、エラー処理の例外を設けることは十分に悪いことだと思います。それにより、ジャンプが隠されますが、通常のフロー制御のために例外を設けることは間違いなく私がしたいことです。コードが汚染され、予測しにくくなったと考えてください。
例外には、アンチ パターンに関する他の多くの記事でも見られる問題があります。
- これらは、多くの点で
goto
ステートメントに似ています。コード内に「見えない」終了ポイントを作成し、通常のデバッガーでコードをステップ実行するのが実際により複雑になる可能性があるポイントで論理的なプログラム フローが中断されるという点です。
- 使用するのに費用がかかります。これについては、以下で詳しく説明します。
- コードが読みにくくなります。
- 設計上の問題の兆候であり、代わりに対処する必要があります。
私はすべての状況で例外に反対しているわけではありませんが、「エラー」状況のすべての処理が例外を使用して行われるべきだとは思いません。「エラー」がプログラムフローにどのように影響するかによって異なります。たとえば、エラー (言葉遣いが悪くて申し訳ありません) が本当に例外的な状態である場合、たとえば、ソケットが死んだり、新しいメモリを割り当てられなかったりする場合などに、非常に理にかなっています。このような場合、特に例外は無視するのが難しいため、例外は理にかなっています。要約すると、私の意見では、例外は例外的な状況に使用する必要があります。
SO およびその他の Stack Exchange サイトでこれに対処する他の回答があり、興味があるかもしれません:
制御フローとしての例外は重大なアンチパターンと見なされますか? もしそうなら、なぜですか?
通常の制御フローとして例外を使用しないのはなぜですか?
例外のパフォーマンスに関する注意。例外処理がどのように行われるかは実装固有であり、コンパイラごとに異なる場合があります。ただし、多くの場合、例外ではないパスを使用する場合、例外は追加のコストを追加しませんが、例外的なパスを使用する場合、コストが実際に重要であることを示唆する多くのレポートがあります ( https://stackoverflow.com/a/13836329/111143例外的なパスの通常の 10 倍/20 倍のコストについて言及していif
ます)。
例外の実装はコンパイラに固有のものであるため、これに対する一般的な答えを出すのは難しい場合があります。ただし、コンパイラによって生成されたコードを調べると、例外を使用するときに何が追加されるかがわかります。たとえば、例外をキャッチする場合、スローされた例外のタイプ情報が必要になります。これにより、例外のスローに追加のコストが追加されます。この追加コストは、めったに起こらない例外的な状態に本当に直面している場合、ほとんど違いはありません。しかし、通常のプログラム フローを制御するために使用すると、コストのかかる作業になります。
たとえば、整数をスローして終了する次の単純なコードの例を見てください: https://godbolt.org/g/pssysLコンパイラが戻り値を最適化するのを防ぐために、グローバル変数が追加されています。これを、戻り値が使用される単純な例と比較してください: https://godbolt.org/g/jMZhT2例外は、非例外パスが使用される場合とほぼ同じコストになりますが、例外パスが使用される場合はより高価になります。例外が本当に例外的な状況に使用される場合、これは問題ありませんが、「例外的なパス」がより頻繁にヒットする状況で使用されると、コストが要因になり始めます。