C ++でのエラー処理のためのtry-catchまたはifs

例外はゲームエンジンの設計で広く使用されていますか、それとも純粋なifステートメントを使用する方が望ましいですか？例外の例：

try {
    m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
    m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
    m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
    m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
    m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
    m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );
} catch ... {
    // some info about error
}

ifsを使用した場合：

m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
if( m_fpsTextId == -1 ) {
    // show error
}
m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
if( m_cpuTextId == -1 ) {
    // show error
}
m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
if( m_frameTimeTextId == -1 ) {
    // show error
}
m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
if( m_mouseCoordTextId == -1 ) {
    // show error
}
m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
if( m_cameraPosTextId == -1 ) {
    // show error
}
m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );
if( m_cameraRotTextId == -1 ) {
    // show error
}

私は、例外がifsより少し遅いと聞いたので、if-checkingメソッドと例外を混ぜてはいけません。ただし、例外として、initialize（）メソッドなどのたびに大量のifよりも読みやすいコードがありますが、私の意見では、たった1つのメソッドには重すぎる場合があります。彼らはゲーム開発のために大丈夫ですか、それとも単純なifに固執しますか？

簡単な答え：Niklas FrykholmによるSensible Error Handling 1、Sensible Error Handling 2、およびSensible Error Handling 3を読んでください。実際に、そのブログのすべての記事を読んでください。私はすべてに同意するとは言いませんが、そのほとんどは金です。

例外を使用しないでください。理由はたくさんあります。主要なものをリストします。

新しいコンパイラではかなり遅くなりますが、実際には遅くなります。一部のコンパイラは、実際に例外をトリガーしないコードパスに対して「ゼロオーバーヘッド例外」をサポートします（ただし、例外処理に必要な余分なデータがまだあるため、実行可能ファイル/ dllサイズが肥大化するため、少し嘘になります）。ただし、最終結果は、はい、例外の使用が遅くなり、パフォーマンスが重要なコードパスでは、絶対に回避する必要があります。コンパイラーによっては、それらを有効にするとオーバーヘッドが追加される場合があります。コードサイズは常に大きくなり、多くの場合かなり大きくなります。これは、今日のハードウェアのパフォーマンスに深刻な影響を与える可能性があります。

例外は、コードをより脆弱にします。悪名高いグラフィック（残念ながら、今は見つけられません）がありますが、これは基本的に、例外安全なコードと例外安全でないコードを書くことの難しさをグラフ上に示しているだけです。単に例外を伴う小さな落とし穴がたくさんあり、例外的に安全に見えるが実際にはそうではないコードを書く多くの方法があります。C ++ 11委員会全体がこれを馬鹿にし、 std :: unique_ptrを正しく使用するための重要なヘルパー関数を追加するのを忘れており、それらのヘルパー関数を使用しても、使用するよりも多くの入力が必要であり、ほとんどのプログラマーはそうしません」もしそうでないなら、何が悪いのかを理解することすらできません。

より具体的には、ゲーム業界向けに、一部のコンソールのベンダー提供のコンパイラ/ランタイムは、例外を完全にサポートしていないか、まったくサポートしていません。コードで例外を使用している場合、この日も年齢もコードの一部を書き直して新しいプラットフォームに移植する必要がありますか？（コンソールがリリースされてから7年間で変更されたかどうかは不明です。例外を使用せず、コンパイラ設定でも例外を無効にしているため、最近話した人が誰もチェックしていないこともわかりません）

一般的な考え方は非常に明確です。例外的な状況には例外を使用します。あなたのプログラムが「何をすべきかわからない、おそらく誰か他の人がそうするかもしれないので、例外を投げて何が起こるか見てみよう」になったときにそれらを使用してください。他のオプションが意味をなさないときにそれらを使用します。誤って少量のメモリをリークしたり、適切なスマートハンドルの使用を台無しにしたためにリソースをクリーンアップできなかったりすることを気にしない場合に使用します。他のすべての場合では、それらを使用しないでください。

あなたの例のようなコードに関して、あなたは問題を解決するいくつかの他の方法を持っています。より堅牢な方法の1つは、単純な例では必ずしも理想的ではありませんが、単項エラータイプに傾くことです。つまり、createText（）は整数ではなくカスタムハンドルタイプを返すことができます。このハンドルタイプには、テキストを更新または制御するためのアクセサーがあります。ハンドルがエラー状態になった場合（createText（）が失敗したため）、ハンドルへの以降の呼び出しは単純に失敗します。また、ハンドルにクエリを実行して、エラーが発生したかどうか、発生した場合は最後のエラーを確認することもできます。このアプローチは他のオプションよりもオーバーヘッドが大きくなりますが、かなり安定しています。本番環境では単一の操作が失敗する可能性があるが、できない/できない/できないという状況で、長い操作の文字列を実行する必要がある場合に使用します

モナドのエラー処理を実装する代わりに、カスタムハンドルオブジェクトを使用するのではなく、コンテキストオブジェクトのメソッドが無効なハンドルIDを適切に処理するようにします。たとえば、createText（）が失敗したときに-1を返す場合、-1が渡されると、これらのハンドルのいずれかを取るm_statisticsの呼び出しは正常に終了します。

同様に、実際に失敗している関数内にエラー印刷を配置できます。あなたの例では、createText（）にはおそらく何が間違っていたかについての詳細な情報があるため、より意味のあるエラーをログにダンプすることができます。この場合、呼び出し元にエラー処理/印刷をプッシュしてもほとんど利点はありません。呼び出し元が処理をカスタマイズする必要がある場合（または依存関係の注入を使用する場合）に行います。エラーがログに記録されるたびにポップアップできるゲーム内コンソールを用意することは良い考えであり、ここでも役立ちます。

統計システム用のテキストBLOBを作成するという単純な行為のように、健全な環境で失敗することはないと思われる呼び出しに対する最良のオプション（上記のリンクされたシリーズで既に提示されています）は、失敗しました（この例ではcreateText）中止します。何かが完全に削除されない限り、createText（）が本番環境で失敗しないことを合理的に確信できます（たとえば、ユーザーがフォントデータファイルを削除したか、何らかの理由で256MBのメモリしかないなど）。これらのケースの多くでは、障害が発生したときに行うべきことすらありません。メモリ不足？ユーザーにOOMエラーを表示するための素晴らしいGUIパネルを作成するために必要な割り当てを行うことさえできないかもしれません。フォントが見つかりませんか？エラーをユーザーに表示することを困難にします。何が間違っていても、

（a）エラーをログファイルに記録し、（b）通常のユーザーアクションに起因しないエラーに対してのみクラッシュを行う限り、クラッシュはまったく問題ありません。

可用性が重要で、ウォッチドッグの監視が十分ではない多くのサーバーアプリでは、同じことはまったく言いませんが、ゲームクライアントの開発とはまったく異なります。また、他の言語の例外処理機能はC ++のように噛みつかない傾向があるため、C / C ++を使用することは避けてください。これらの環境は管理された環境であり、C ++の持つ例外安全性の問題はすべてありません。サーバーは、ゲームクライアントのような最小遅延保証よりも並列性とスループットに重点を置く傾向があるため、パフォーマンスの懸念も軽減されます。シューティングゲームなどのアクションゲームサーバーでさえも、たとえばC＃で記述された場合、FPSクライアントのようにハードウェアを限界までプッシュすることはめったにないため、非常に機能します。

ドナルドクヌース自身の古い知恵は次のとおりです。

「私たちは小さな非効率性を忘れて、約97％の時間を言うべきです。時期尚早な最適化はすべての悪の根源です。」

これを大きなポスターとして印刷し、本格的なプログラミングを行う場所ならどこにでも置いてください。

したがって、 try / catchが少し遅い場合でも、デフォルトで使用します。

• コードはできるだけ読みやすく、理解しやすいものでなければなりません。あなたは可能性が一度コードを書いていますがします、このコードをデバッグするため、他のコードをデバッグするため、理解するための、改善のためにそれをより多くの回を読みます...

• パフォーマンスに対する正確さ。if / elseを正しく行うことは簡単ではありません。この例では、1つのエラーが表示されるのではなく、複数のエラーが表示される可能性があるため、誤って実行されます。カスケードif / then / elseを使用する必要があります。

• 一貫した使いやすさ：Try / catchは、すべての行でエラーをチェックする必要のないスタイルを採用しています。一方：一つ欠けている場合/ elseとあなたのコードのかもしれないの難破船の大混乱。もちろん、再現不可能な状況でのみ。

最後のポイント：

例外はifsより少し遅いと聞きました

約15年前、最近信頼できる情報源から聞いたことがないと聞いた。コンパイラは改善されているかもしれません。

要点は、時期尚早な最適化を行わないことです。手元のコードが頻繁に使用されるコードのタイトな内部ループであり、切り替えスタイルによってパフォーマンスが大幅に向上することをベンチマークで証明できる場合にのみ実行してください。これは3％のケースです。

この質問に対する回答は既に非常に優れていますが、特定のケースでのコードの可読性とエラー回復についての考えを追加したいと思います。

あなたのコードは実際には次のように見えると思います：

m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );

例外も、ifもありません。エラー報告はで行うことができますcreateText。またcreateText、戻り値を確認する必要のないデフォルトのテクスチャIDを返すことができるため、残りのコードも同様に機能します。