ゲームプログラミングのTry / CatchとFinalsのステートメントを学ぶことは不可欠ですか、それとも戻ってくることができるものですか？[閉まっている]

GAMEプログラミングの本質的な部分とは思えない。

彼らは100％不可欠です。エラーが発生したときにゲームをクラッシュさせますか？確かに、いくつかのエラーは常にクラッシュを引き起こしますが、ネットワークタイムアウトのような単純なものはどうでしょうか。プレーヤーに伝えてもう一度試すか、ネットワーク接続を確認するほうが賢明ではないでしょうか？

それらを拾うことは非常に簡単です。

try
{
    //open a network connection and try to get the leaderboard 
}
catch(Exception ex)  //type of exception, and a variable to access it by
{
    //tell the user something happend, and have them try again.
    //maybe you jut want to log it.

    LogError(ex);
    //so we have a record it happend, but the error was really bad! (out of memory) just throw it again if you need to
    throw;
}
finally
{
    //this happens no matter what. it will run on success and failure
}

例外処理は学習に役立つスキルであるというジョーの回答には同意しますが、ゲーム開発でめったに使用されないのは私の経験です。

実装の違いはよくわかりませんが、C ++では、「スロー」が発生したときにスタックトレースを維持して効果的な巻き戻しを可能にするためのオーバーヘッドが、眉をひそめる唯一の理由です。

この回答は、C＃例外処理に関連するオーバーヘッドについての洞察を提供する可能性があります。

一般的なプログラムアーキテクチャの観点では、例外はクラッシュの正確な理由を特定するのに役立ちません。また、エラーが発生している場所を正確に特定するのは面倒です。キャッチのポイントまでくつろぎますが、エラーの実際の発生場所に関する情報は（例外の有用性によって異なりますが）ほとんどありません。

それはあなたが戻ってくることができるものであることに同意します。

メンテナンス/プログラミングをサポートするための「ゲームプログラミング」は、おそらく不可欠ではありません。言い換えれば、「ゲームプログラミング」をゲームの作成と配信の分野と考えることができる場合、例外処理のメリットは、出荷後に明らかになります。

そうは言っても、どれだけ早く役割を果たすことができるものがあります：

• ロギング。したがって、エラー管理戦略の策定を開始するポイントがあります。戦略をどのくらい早く作成するかは、バグレポートや「null参照」などのキャプチャされたログエントリから受けるサポートの量に直接関係します。多くの場合、例外からキャプチャできるコンテキストがないと、より多くの検出作業を実行する必要があり、類似性を確認するためにエラーをグループ化することがより困難になります。

• パッチシステム。更新をプッシュできる場合は、例外処理の実行を待つ自由がたくさんあります。ロジックがWebアプリでクライアントが単なるブラウザーの場合も同様です。

• あなたのチームのサイズ。あなたが一人のチームであるならば、あなたは待つために途方もない自由を持っています。あなたはあなたのコードを知っています。例外がtodoリストにあることを事前に知っているかもしれません。作業して他の開発者とコードを共有する場合、他の誰かのコードを追跡するためのチケットが割り当てられる可能性があるため、例外がどこにトリップしたのかすぐにはわかりません。

• 並行性。私にとって、これは計画するのが難しいので、努力する価値はないかもしれません。また、これは堅牢性または弾力性の一部だと感じています。したがって、要件が突然のクラッシュを許容する場合は、大きな自由があるため、例外に対処するまで待機します。スレッドで見つかる可能性があることの1つは、非決定的な動作を簡単に取得できることです。これが発生した場合、障害に至るまでの状態に関する情報をできるだけ多く取り込む方法が必要です。これには、マシンのラボでのシミュレーション、回帰テスト、ログ、（ライブ）データを含めることができます。個別にこれらの各部分は、他の部分をある程度相殺できます。たとえば、無限のテストがある場合、すべてのロジック障害を公開できるため、例外処理（またはロギングなど）は必要ありません。

例外処理は、ゲームの任意の時点からの予期しないエラーを処理するためのより明確な方法です。しかし、その美しさは、コードベースでは、コードをどれだけ深く処理しても問題になりません。例外なく、ある種のエラー処理ルーチンは、ある種のステータスに対してboolまたはintを返し、次にネストされたサブルーチンを展開して、最上位の領域（ゲームクラス）に到達し、そこから終了します。例外を使用するのであれば、リファクタリングをほとんどまたはまったく必要としないので、可能な限りあらゆる点からエラーチェックにコードを書き込むのは非常に面倒になります。

あなたの質問はXNA固有なので、Xboxゲームで例外を処理する方法を知ることはおそらく役に立ちます。そこでゲームが例外をキャッチしない場合、それが発生した理由についての手掛かりが残されないためです。この記事では、try / catchブロックでゲーム全体を実行することで問題を回避するための賢い方法を示します。何か問題が発生した場合、新しい「ExceptionGame」を起動し、ExceptionGameに表示するエラーの詳細を渡します。

C＃については何も知りませんが、ここでは3セントです。

1. try / catch / finally例外処理パラダイムは広く普及しており、それには十分な理由があります。コード内の例外を処理するための優れたフレームワークを提供します。
2. 特定の言語を使用している場合は、そのすべてのステートメントとその使用方法を学習する必要があります。そうしないと、コードがわかりにくく、バグが多く、非効率的なものになります。プログラミング言語の設計には多くの考慮が払われており、利用可能なすべてのツールを使用せずにプログラムを作成しようとするのは... ばかげています。
3. 侮辱的ではありませんが、ゲーム開発には多くの挑戦的な側面があり、「私が絶対に必要なものを学ぶだけだ」という態度でそれをしようとすることはうまくいきません。ゲームを開発するという目標への道のりを、できるだけ多くのことを学ぶ機会として利用するほうがよいでしょう。

いいえ、例外は絶対に重要でも必須でもありません。ほとんどの場合、従来のゲームプログラムはエラーチェックに非常に負荷がかかり、データとパラメータで何が起こっているかを正確に把握しています。

これに対する例外は、システムコールにアクセスする場合であり、それらは例外をスローし、それらをキャッチする方法は非常によく文書化されており、自分で例外をより深く使い始めるまで、ブラックボックスのようにtry / catchを使用できます。

全体のtry / catchの事はあるピックアップし、あなたがC＃に慣れたら、あなたは例外が理にかなって、あなたが自然に独自のコードにそれらを追加するために始めることができる場所を確認することができます非常に簡単しかし。

もちろん、あなたはまだ始まったばかりだと仮定します。他の言語の後にC＃を学習している場合は、例外を取り上げて、後で待つ必要があります。

それはあなたのゲームコードの性質に依存すると私は信じています。実行の流れの中で、失敗する可能性のある領域はありますか？コードは100％処理されていますか？コードに失敗する方法がなく、事後条件とそれに確実に気づいている場合、例外処理はほとんど役に立ちません。理由もなくチェックするためにリソースの使用を増やします。ただし、コードの大部分には、問題が発生する可能性がある状況があります。特にゲーム開発において、ゲームが予測可能である場合、それはゲームであるという本質を欠いている可能性があります。ゲーム開発での使用に関係なく、それとその使用方法を知っておく必要があります。ただし、必要に応じて適用してください。

ブレークポイントを挿入したり、コード全体を調べたりせずに、urプログラムで何が問題だったかを知りたいですか？はいの場合、try-catchステートメントはそれを行うのに役立ちます。これは、事前設定されたタイプのエラーを使用して何が問題になったかを示します。したがって、これらのステートメントを実際に学習し、どのエラーが何を意味するかを知ることにより、手間をかけずにコードを効果的にデバッグできます。

上手、

通常、オブジェクト指向ソフトウェアは、実行中のプロセスのエラーを報告するために例外を使用する傾向があります。現在のメソッドが対処/解決できないことが発生した場合は、例外をスローし、上級者がこの問題を処理できるようにする必要があります。このようにすると、主な処理方法（より具体的な方法）は、解決できないエラーを処理する必要がなく、よりクリーンになります。

ただし、通常、ゲーム開発では、穴の環境を設計しているため、例外はスローされません。エンジンを設計している場合、はい、基本的にI / O機能の例外を使用しますが、たとえば、シーンでは、それを使用することはほとんどありません。エラーをスローするのではなく、解決する必要のある事柄のリストに追加する方がよいことがわかりました。たとえば、クライアント/サーバーゲームがあるとします。クライアントで、問題が発生していることに気付きました。シーケンスを壊すのではなく、解決する必要があるエラーのリストにこのエラーを追加する方が（私にとって）良いと私は思います。そうすれば、このエラーをジャンプして例外をスローしないで、誰かがこの問題を修正しようとします。

ただし、使用するOOソフトウェアでは、例外が常に使用されることに注意してください。学ぶことは本当に良いことで、とても便利で、難しいことではありません。