Javaのバックグラウンドを持つ開発者として、私は例外をキャッチしてアプリのクラッシュを防ぐことに慣れています。これには、あらゆる種類のデリゲートメソッドが含まれます。予期しない状況に対する追加の安全対策。
私の質問は、そのようなアプローチがObjective cで賢明であるかどうか、そしてそれはある種のパフォーマンスの問題を引き起こすかどうかです。言い換えれば、try / catchブロックをより頻繁に使用すると、アプリは何らかの形で苦しむでしょうか？
質問する
1938 次
7 に答える
7
それほど苦しむことはありませんが、何かを覚えておく必要があります。あなたが持っているかもしれない他の言語とは異なり、ConnectionRefusedExceptionobjective FileNonexistantException-cでは、例外は90％の確率でプログラマーエラーです。したがって、アプリが本番環境に移行するまでには、とにかく例外はありません。たとえば、範囲外の例外をキャッチするのではなく、試行する前に配列の長さを確認するだけです。エラーが発生し、クラッシュよりも正常に終了する場合に備えて、トップレベルのtry-catchを作成できます。
于 2012-12-18T15:30:54.703 に答える
1
一般に、プログラムの実行中に例外が発生することは望ましくありません。したがって、エラーが発生した後にキャッチするのではなく、エラーが発生する前にテストする方がプログラミングの実践として優れていると考えられます。
また、メソッドのエラーをテストし、例外をスローするよりもエラーインジケーターとして値を返す方が適切です。例外をスローすると、多くのシステムリソースが使用されるため、
Appleは通常、それらの不要な使用を使用しないことをお勧めします（たとえば、ファイルを開くことができないという理由だけで例外をスローしたくない場合）。
于 2012-12-18T15:32:28.043 に答える
1
ベストプラクティスは、データ、モジュール、ファイル、およびユーザー環境設定やユーザーが送信したデータが原因で機能しない可能性のあるものをロードする場合にのみ、tryandcatchを使用することです。
于 2012-12-18T15:33:53.340 に答える
0
例外は例外であり、それほど頻繁に発生することはないはずです:)）、パフォーマンスにはまったく影響しません。
通常、プロトコルには通常の動作とエラー[eg didLoadResponse: theResponse、didFailWithError: theError]の両方のデリゲートメソッドが含まれているため、すべての状況がカバーされます。
ディスクへの書き込みエラーやリモートサーバーのダウンなどの状況（実際にはアプリケーションが破損する状況）には例外を残しておきます。
于 2012-12-18T15:32:16.340 に答える
0
パフォーマンスの問題が発生する可能性があります。例外がスローされた場合は、プログラムのデバッグ中は問題ありませんが、アプリケーションがそこで実行されている間は、これが発生することを望まない場合があります。
私の提案は、デバッグにのみ例外を使用し、リリースでは例外を無効にして、NSErrorなどのより適切なアプローチを使用することです。
ユーザーがURLを入力し、このURLが無効であると仮定します。Webページをロードする必要があります。デバッグ中に例外をスローする場合がありますが、リリースがある場合は、間違ったURLを無視するだけで、無視しないでください。ページを表示するか、NSAlertPanelを実行してエラーを表示します。
于 2012-12-18T15:33:29.720 に答える
0
tty / catchは例外にのみ使用し、if/thenの代わりには使用しないでください。オーバーヘッドは非常に高くつきます。
于 2012-12-18T15:35:37.130 に答える
0
iPadでテストをしました。@ try / @ catchブロックは、例外が実際にスローされない限り、パフォーマンスの低下をほとんどもたらさないようです。ただし、例外がスローされた場合、ペナルティはかなりのものになります。使用している環境はわかりません。したがって、マイレージは異なる場合があります。
于 2013-04-23T17:52:06.513 に答える