Try / Catchを論理演算子として使用するかどうかの引数[非公開]

Try-Catchブロックを論理演算子として使用する会社のアプリで素敵なコードを発見しました。
つまり、「何らかのコードを実行し、このエラーがスローされる場合、このコードを実行しますが、それがこのエラーをスローする場合、代わりにこの3番目の処理を実行します」。
表示される「else」ステートメントとして「finally」を使用します。
私はこれが本質的に間違っていることを知っていますが、戦いを始める前に、よく考えられた議論を望んでいました。
また、この方法でTry-Catchを使用するための引数がある場合は、教えてください。

疑問に思っている人にとっては、言語はC＃であり、問​​題のコードは約30行以上あり、特定の例外を探しています。すべての例外を処理しているわけではありません。

例外処理は、フロー制御を処理するための高価な方法になる傾向があります（C＃およびJavaの場合は特に）。

例外オブジェクトが構築されると、ランタイムは非常に多くの作業を行います-スタックトレースを取得し、例外が処理される場所を特定します。

フロー制御にフロー制御ステートメントを使用する場合、これらすべてのメモリとCPUリソースのコストは、拡張する必要はありません。

さらに、セマンティックの問題があります。例外は例外的な状況であり、通常のフロー制御ではありません。通常のプログラムフローとしてではなく、予期しない/例外的な状況を処理するために例外処理を使用する必要があります。

これら2つとは別に、コードを読む他の人の問題があります。このような方法で例外を使用することは、ほとんどのプログラマーが期待するものではないため、読みやすさとコードの理解しやすさが損なわれます。「例外」を見たとき、考えます-何か悪いことが起こった、通常は起こらないはずの何か。そのため、この方法で例外を使用するのは簡単です。

Try-Catchブロックを論理演算子として使用する会社のアプリで素敵なコードを発見しました。つまり、「何らかのコードを実行し、このエラーがスローされる場合、このコードを実行しますが、それがこのエラーをスローする場合、代わりにこの3番目の処理を実行します」。表示される「else」ステートメントとして「finally」を使用します。私はこれが本質的に間違っていることを知っています...

どうやってわかったの？私はそのような「知識」をすべてあきらめ、今では最も単純なコードが最良であると信じています。解析が失敗した場合に空の文字列をOptionalに変換するとします。問題はありません：

try { 
    return Optional.of(Long.valueOf(s)); 
} catch (NumberFormatException) { 
    return Optional.empty(); 
}

「例外は例外的な条件のためである」という通常の解釈にはまったく同意しません。関数が使用可能な値を返せない場合、またはメソッドが事後条件を満たせない場合、例外をスローします。パフォーマンスの問題が実証されるまで、これらの例外がどのくらいの頻度でスローされるかは関係ありません。

例外は、エラー処理を通常のフローから分離できるようにすることで、コードを簡素化します。できるだけ簡単なコードを書くだけで、try-catchを使用したり例外をスローしたりするのが簡単な場合は、それを実行してください。

例外は、コードを通るパスの数を減らすことでテストを簡素化します。分岐のない関数は、完了するか例外をスローします。ifエラーコードをチェックする複数のステートメントを持つ関数には、多くのパスがあります。条件の1つを間違えたり、完全に忘れることが非常に簡単であるため、エラー条件が無視されます。

例外を使用して制御フローを実行する場合、デバッグおよびメンテナンス作業は非常に困難です。

本質的に、例外は、プログラムの通常の制御フローを変更するためのメカニズムとして設計されています-それほど複雑では処理できない特に厳しいバインドから抜け出す方法として、異常なアクティビティを実行し、異常な副作用を引き起こす手段。例外は例外的です。これは、作業している特定の環境に応じて、通常の制御フローに例外を使用すると以下が発生する可能性があることを意味します。

• 非効率性例外に必要な比較的困難なコンテキストの変更を安全に実行するために環境がジャンプしなければならない追加のフープには、機器とリソースが必要です。

• デバッグの難しさ例外が発生すると、（プログラムをデバッグするときに）役に立つ情報がウィンドウからスローされることがあります。実行時の動作の理解に関連するプログラムの状態や履歴を追跡できなくなる場合があります

• メンテナンスの問題実行フローは、例外のジャンプを追跡するのが困難です。それを超えると、例外がブラックボックス型コード内からスローされる場合があります。これは、例外をスローするときにわかりやすい方法で動作しない場合があります。

• 不十分な設計決定この方法で構築されたプログラムは、ほとんどの場合、問題をエレガントに解決するのに簡単に対応できない心のフレームを奨励します。最終プログラムの複雑さは、プログラマーがその実行を完全に理解することを妨げ、高いコストで短期的な改善につながる決定を下すことを奨励します。

このパターンが何度か使用されているのを見てきました。

2つの大きな問題があります。

• 非常に高価です（例外オブジェクトのインスタンス化、呼び出しスタックの収集など）。一部のコンパイラは実際にそれを最適化できるかもしれませんが、例外はそのような使用を目的としていないため、この場合は期待しません。したがって、人々が最適化することは期待できません。
• 制御フローに例外を使用することは、実際にはジャンプgotoです。ジャンプは、いくつかの理由で有害であると考えられています。すべての選択肢にかなりの欠点がある場合は、それらを使用する必要があります。実際、すべてのコードで、ジャンプが明らかに最善の解決策であった2つのケースしか思い出せません。

例外が最も速い場合があります。Javaでも制御構造を使用するよりもNULLオブジェクト例外が速い場合があります（現時点ではこの研究を引用できないため、私を信頼する必要があります）。問題は、Javaが実際に時間がかかり、ネイティブなもの（少なくとも部分的にキャッシュされているように見える）を使用する代わりに、カスタム例外クラスのスタックトレースを設定する必要がある場合に発生します。何かが一方的に速いか遅いと言う前に、ベンチマークするのは良いことです。

Pythonでは、高速であるだけでなく、例外を発生させてエラーを処理する可能性のある処理を行う方がはるかに正確です。はい、型システムを強制できますが、それは言語の哲学に反します。代わりに、メソッドを呼び出して結果をキャッチしようとする必要があります。（ファイルが書き込み可能かどうかのテストも同様です。単に書き込みを試みてエラーをキャッチしてください）。

PHP + MySQLにテーブルが存在するかどうかを確認するよりも、クエリテーブルのような愚かなことをするほうが速い場合があります（これをベンチマークする質問は、実際に唯一の負の投票で受け入れられた答えです） 。

それにもかかわらず、いくつかの理由で例外の使用を制限する必要があります。

1. ネストされた例外の偶然の飲み込み。これはメジャーです。他の誰かが処理しようとしている深くネストされた例外をキャッチした場合、仲間のプログラマー（おそらくあなたも！）
2. テストは非自明になります。例外を含むコードブロックには、いくつかの問題があります。一方、ブール値は、理論的にはデバッグするのが面倒ですが、一般的にはそうではありません。try...catch制御フローの支持者は一般に（私の経験では）「tryブロックのコードを最小化する」という哲学に従っていないため、これは特に当てはまります。
3. else ifブロックは許可されません。十分に言った（そして誰かが「異なる例外クラスを使用できる」と反論した場合、私の応答は「あなたの部屋に行って、あなたが言ったことを考えるまで出てこない」です）。
4. 文法的に誤解を招く。 Exception、（try...catch制御フローの哲学に固執していないように）他の世界に、何かが不安定な（おそらく回復可能）状態に入ったことを意味します。不安定な状態は悪い状態であり、実際に回避可能な例外がある場合は、夜中ずっと私たちを維持する必要があります（実際にはうそをつきます、嘘はありません）。
5. 一般的なコーディングスタイルに準拠していません。私たちの仕事は、コードとUIの両方で、世界を可能な限り明確にすることです。try...catch制御フローは、一般的にベストプラクティスと見なされるものに反します。これは、プロジェクトに慣れていない人がプロジェクトを習得するのに時間がかかることを意味します。つまり、まったく工数がかからずに工数が増えることを意味します。
6. これはしばしばコードの重複につながります。最後に、これは厳密には必要ではありませんが、中断されたtryブロックによって開かれたままになっているすべてのダングリングポインターを解決する必要があります。ブロックを試してください。これは、try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}。より伝統的なif...elseシナリオではcloseSomething()、コピーアンドペーストジョブになる可能性は低くなります（再び、個人的な経験）。（確かに、この特定の議論は、実際の哲学そのものよりも、私が出会った人々と関係があります）。

私の主な論点は、論理にtry / catchを使用すると論理フローが壊れることです。非論理構造を介して「論理」に従うことは、（私にとって）直感に反し、混乱を招く。私は自分のロジックを「if Condition then A else B」と読むことに慣れています。「A catchを実行してからBを実行してください」と同じ文を読むのは奇妙に感じます。ステートメントAが単純な割り当てであり、conditionfalseがfalseである場合に例外を強制するための追加のコードが必要な場合はさらに奇妙になります（ifとにかく-statementが必要になります）。

まあ、エチケットの問題は、「彼らと議論を始める」前に、あなたが述べているように、私は親切に「なぜ彼らはこれらすべての異なる場所で例外処理を使用するのですか？」

つまり、いくつかの可能性があります。

1. 彼らは無能です
2. 彼らがしたことには完全に正当な理由があり、それは一見しただけでは現れないかもしれません。
3. 時々それは好みの問題であり、いくつかの複雑なプログラムの流れを単純化するかもしれません。
4. 誰もまだ変わっていないのは過去の遺物で、誰かがそれをやれば幸せになる

...これらはすべて同様に可能性が高いと思います。丁寧に聞いてください。

Try Catchは、例外処理にのみ使用する必要があります。さらに、特定の例外処理。try catchは、予期される例外のみをキャッチする必要があります。そうでない場合、整形式ではありません。catch all tr​​y catchを使用する必要がある場合は、おそらく何か間違ったことをしている可能性があります。

編集：

理由：try catchを条件演算子として使用する場合、REAL例外をどのように考慮しますか？

例外は、例外的なことが起こるときのためのものです。プログラムは通常のワークフローに従って例外的に機能していますか？

例外を使用する理由：

1. 例外的な状況をキャッチするのを忘れると、プログラムは停止し、スタックトレースはその正確な理由を示します。例外状況の戻り値を処理するのを忘れた場合、プログラムが誤った動作を示す距離はわかりません。
2. 戻り値の使用は、戻り可能なセンチネル値がある場合にのみ機能します。可能なすべての戻り値がすでに有効な場合、何をしますか？
3. 例外には、発生した可能性のある有用な追加情報が含まれます。

例外を使用しない理由：

1. 多くの言語は、例外を迅速に作成するようには設計されていません。
2. スタックのいくつかのレイヤーを移動する例外は、その後に一貫性のない状態を残す可能性があります

最終的には：

目標は、何が起こっているかを伝えるコードを書くことです。例外は、コードの実行内容に応じて、それを支援/妨害する可能性があります。辞書参照のKeyErrorに対するPythonのtry / catchは（言語を知っている限り）完全に5関数レイヤー離れた同じKeyErrorのtry / catchは危険です。

特定の状況では、フロー制御としてtry-> catchを使用します。プライマリロジックが失敗したものに依存しているが、例外をスローして終了したくない場合...それがtry-> catchブロックの目的です。私は多くの監視されていないサーバー側のUNIXスクリプトを書いていますが、それらが失敗しないことは、それらがきれいに失敗することよりもはるかに重要です。

そうしようと計画Aは、本プランAの死亡した場合、キャッチ使用、プランBとし、実行...そしてプランBは、失敗した場合、最終的にどのフィックスAまたはBで失敗したサービスのいずれか、またはページのどちらかだろう、プランCキックオフへ私。

それは言語と、おそらく使用されている実装に依存します。C ++の標準では、真に例外的なイベントに対して例外を保存する必要があります。一方、Pythonのガイドラインの1つは「許可よりも許しを求める方が簡単」であるため、プログラムロジックへのtry / exceptブロックの統合が推奨されます。

それは悪い習慣ですが、私は時々Pythonでそれをします。ファイルが存在するかどうかを確認する代わりに、ファイルを削除しようとします。例外がスローされた場合、私はキャッチし、それがそこになかったことを知って先へ進みます。<==（別のユーザーがファイルを所有している場合は必ずしも当てはまりませんが、ユーザーのホームディレクトリで実行するため、このような事態は発生しません）。

それでも、使いすぎると悪い習慣になります。

Appleが定義する方法が気に入っています。例外はプログラマーエラーと致命的なランタイムエラーのみです。それ以外の場合は、エラーコードを使用します。「これはプログラマーのエラーだったのか？」と思いながら、いつ使用するかを決めるのに役立ちます。

これは、gotoコマンドを持たない言語の上にgotoロジックを構築するために例外処理を使用しているように聞こえます。

gotoロジックが悪い多くの理由については、この質問を参照できます：https : //stackoverflow.com/questions/46586/goto-still-considered-harmful