5

私は C++ ゲーム プログラミングのキャリアをこれまでのところほとんど例外に触れずにやり遂げてきましたが、最近は Ogre エンジンを使用したプロジェクトに取り組んでおり、適切に学習しようとしています。C++ 例外の一般的な使用法については、ここで多くの良い質問と回答を見つけましたが、Ogre の使用法が適切かどうか、およびそれらを使用する最善の方法について、外部の意見をここから得たいと思います。

まず、独自の Exception クラスの Ogre のドキュメントから引用します。

OGRE は戻り値を使用してエラーを示すことはありません。代わりに、エラーが発生した場合、例外がスローされます。これは、問題の詳細をカプセル化するオブジェクトです。OGRE を使用するアプリケーションは常に例外がキャッチされるようにする必要があるため、すべての OGRE エンジン関数は try{} catch(Ogre::Exception& e) {} ブロック内で発生する必要があります。

本当に？すべての Ogre 関数が例外をスローし、try/catch ブロックにラップされる可能性がありますか? 現在、これはメインの try/catch によって処理され、終了する前に例外の説明を含むメッセージ ボックスが表示されます。これは、スタック トレースを取得せず、エラーをスローした関数だけを取得するため、デバッグには少し厄介な場合があります。より重要なのは、Ogre 関数を呼び出したコードの関数です。それが Ogre コードのアサートであれば、デバッガーのコードに直接行き、何が起こっているかをはるかに簡単に見つけることができます。すでに例外をデバッグしていますか?

現在、コードにさらにいくつかの try/catch ブロックを追加し始めており、Ogre 関数が例外をスローした場合に問題があるかどうかを一般的に考えています。それがすべての動作を停止させるものである場合は、メインの try/catch に処理させてプログラムを終了させます。それほど重要でない場合は、関数呼び出しの直後にキャッチして、プログラムを続行させます。これの最近の例の 1 つは、エンティティに適用されるマテリアルの頂点/フラグメント プログラム パラメーターのベクトルを構築することでした。マテリアルにパラメーターがない場合、例外がスローされます。パラメータのリストに追加する必要はありません。これは物事を処理する合理的な方法のように思えますか? Ogre を使用するための具体的なアドバイスをいただければ幸いです。

4

3 に答える 3

19

Ogre への最後の呼び出しをすべて でラップする必要はありませんtry { ... } catch。例外を有意義に処理できる場所ならどこでもそれを行います。これは、個々の呼び出しサイトにある場合もあれば、何らかの高レベルのループにある場合もあります。どこでも意味のある方法で対処できない場合は、まったく捕まえないでください。デバッガーに引き継がせます。

特に、引用した正確な理由で例外をキャッチするべきではありませんmain()(少なくとも、開発中ではなく、本番環境ではキャッチする必要があります)。

于 2010-04-29T11:32:28.740 に答える
6

例外をデバッグする方法を知らないようです。また

  • VS Debug/Exceptions ダイアログを表示し、C++ Exceptions ボックスにチェックマークを付けます。これにより、例外がスローされたときにデバッグする機会 (ダイアログが表示されます) が得られます。

また

  • Ogre ソースをビルドした場合は、Ogre::Exception コンストラクターにブレークポイントを設定します。ブレークポイントをスローしようとすると、次のレベルがスロー サイトであるコール スタックでブレークします。
于 2010-04-29T11:38:44.877 に答える
6

私は Ogre について何も知りませんが、例外処理の一般的なルールは、スロー サイトから可能な限り離れた場所で例外をキャッチすることですが、それ以上はキャッチしないことです。ただし、これは、例外をスローするコードが RAII を使用して割り当てられたリソースを処理する場合にのみ可能です。コードがプレーン ポインターへの動的割り当て、またはその他の形式の手動リソース管理を使用する場合、呼び出しサイトに try ブロックが必要です。この場合、例外の使用は悪い考えだと思います。

于 2010-04-29T11:33:00.760 に答える