より良いコーディングの実践/より効率的なコードの作成/よりきれいに見える/何でもあなたの考えをいくつか教えてください：潜在的な問題を予測してキャッチするためにifステートメントを使用する能力を向上させますか？それとも、単にtry / catchを一般的にうまく利用していますか？
これがJava用だとしましょう（重要な場合）。
編集： 私は現在、明らかに時代遅れで制約のある現在のコーディング慣行から自分自身を移行していますが、いくつかの点（このような）でそうする必要性に少し引き裂かれています。私は単にこれについていくつかの見方を求めています。議論ではありません。
この討論 (2003) は良かった:
http://www.joelonsoftware.com/items/2003/10/13.html
http://nedbatchelder.com/blog/200310/joel_on_exceptions.html
ifブロックはわずかに高速です。それらを何十個も必要としない場合は、try/catches. 例外は、コードが実行されるたびにではなく、例外的であるべきです。サーバーの切断などのまれなイベント (毎日数回発生しますが) には例外を使用しif、制御可能な変数にはブロックを使用します。
作成しているコードに関係なく、最終的には両方を使用することになります。Javaランタイムについて話すことはできませんが、.NETランタイムでは、try-catchブロックの使用に関連するパフォーマンスの低下があります。その結果、（問題の存在をログに記録しているだけの場合でも）一度キャッチされた例外を処理する明確な方法がある領域でのみそれらを使用しようとしています。
コードでtry-catchブロックまたはif-elseブロックのいずれかを多数使用している場合、またはメソッドがかなり長くなる傾向がある場合は、コードをより多くの小さなメソッドにリファクタリングすることを検討してください。ロジックの意図に従うのが簡単になるだけでなく、単体テストも簡単になります。
ステートメントの方がいいと思います。コードのすべての行をtry..catchで囲むことはできません（できますが、実行しないでください）。コードのブロックをtrycatchで囲むことはできますが、すべての行を囲むことはできません。
そして例外は物事を遅くします。
経験豊富な開発者やアナリストから聞いた話によると、try/catch はよりオブジェクト指向であり、if はより手続き的です。
私は個人的に気にしません。
try/catch の方が遅く、パフォーマンスが低下するという事実は承知していますが、やりたいことを実行する前に多数の if を使用して検証する場合は、常に try/ を使用します。 catch を使用してコードの行数を節約します。
何も検証する必要がなく、ステートメントが失敗した場合は、「else」ブロックで行っていたであろうことを行うだけで、私の人生がとても楽になります...「catch」ブロックで。
場合によっては、もちろん、いくつかの if ステートメントを try/catch で囲みますが、とにかくです。
必要なことを実行する前に、検証することが少数 (1 つまたは 2 つ) しかない場合は、if を使用します。
私の 2p: try/catch を使うのがベストです:
私の経験では、if-conditional-logic を使用すると、エラー処理とビジネス ロジックを区別することが難しくなります。
ここで言及されていないことが 1 つあります。
if-else ステートメントを使用すると、コードが実行されるたびに、少なくとも 1 つの条件が実行されることが保証されます。if-else-elseif がどのように機能するかは誰もが知っていると思いますが、明確にするために... ステートメントのif部分は常に評価され、false の場合は次のelse-ifが評価され、というように続くまで続きます。 elseだけが評価されます。
したがって、if-else ステートメントを使用すると、パフォーマンスに影響します。それほど大きくはありませんが (ほとんどの場合)、評価の実行には CPU 時間がかかります。
try-catch ステートメントを使用してください。間違っている場合は訂正してください。必要になるまで実行時に考慮しないでください (つまり、例外がスローされます)。したがって、コードを try-catch でラップするだけでは、例外が実際にキャッチされるまでパフォーマンスに影響しません。
また、パフォーマンスヒットの原因はキャッチではなく、スローです。
重要なポイントの 1 つは、try-catch ステートメントを条件付きロジックに使用してはならないということです。それらは、設計された目的、つまり例外処理のためにのみ使用する必要があります!
例外の処理方法がわかっている場合は、例外をキャッチすることが不可欠です。例外を適切に処理する方法がない場合は、それを手放すべきです。チェーンのさらに上のコードには、それを処理するためのより良い方法がある場合があります。
通常、アプリケーションの絶対最上位レベルに例外ハンドラーを配置して、ユーザーに表示される前に例外をキャッチすることをお勧めします。ASP.NET では、global.asax の Application_Error イベントでこれを行うことができます。他の言語/環境では、それが何であれ、メインループでそうします。
ただし、常にキャッチされないままにしておくのが最善の例外がいくつかあることに注意してください。場合によっては、例外が発生すると、アプリケーションの状態が著しく損なわれ、信頼できないことを示していることがあります。唯一の安全な方法は、強制終了して再起動することです。
@PersonalPerson - 申し訳ありませんが、これは怠惰なコーディングです。if ステートメントが多すぎるために try-catch を使用するのではなく、コードをリファクタリングしてみませんか (つまり、検証ロジックを独自のメソッドに入れます)。これにより、コードがよりクリーンで読みやすくなり、パフォーマンスのベスト プラクティスが維持されます。
最小の行数を達成するようにコードを記述しようとしないでください。これは常に悪い結果になります。確かに、あなたのコーダー仲間がうんざりする何かを書くためのよりエレガントな方法を見つけることができますが、それは物事を読みにくくするだけです.
私は誓います、私は以前にあなたのコードを扱ったことがあり、頭が痛くなりました.