新しい例外をスローするか、新しい例外をスローしないか、それが問題です！
良い時間を！
例外テクノロジーを使用する場合 いつ棄権した方が良いですか、そして棄権する価値はありますか？
少し前に、この手法を適用する価値がある場合とそうでない場合に、例外アプローチを適用する方法を説明しようとしました。 私にとっては、実際にではなく、穏やかに置くことができました。 しかし、私は「健康な」批判の一部を得ました:)。 どうもありがとうございました： smira habralan tagirovarthur Thecentury 。 だから、気にしない人は、プラスを彼らと共有することができます;）。
ビジネスに取り掛かろう
自分に質問したら、「例外テクノロジーをいつ使用すべきか？」（C＃に重点が置かれています）。 時々、それを使用するかどうか疑問に思うなどの状況があります...インターネットをさらに掘り下げてみると、例外を使用する支持者と反対者の2つのキャンプがあることがわかりました。 ジョエル・スポルスキー率いる敵陣営。
Joelが使用する引数のリストは次のとおりです。
1.ソースコードでは「表示されません」。 詳しく説明します。 特定のクラスのメソッドを呼び出すと仮定します。
someClass.SomeMethod（）;
例外がスローされるかどうかを確実に言うことはできません。 スリッパを投げる必要はありません。VisualStudioでメソッドにカーソルを合わせると、スローできる例外についてのヒントを確認できます（開発者がこの説明をドキュメントで作成した場合）。 他のIDEでどのように動作するのかわかりませんが、VSではそのような機会があります。 もちろん、これは、「真の信仰」、メモ帳（または類似物）、コンパイラーを公言する人々にとって明確なマイナスです。
2.メソッドから「予期しない」出口点が作成されます。 次のようなものがあるとします：
someClass.PossibleException（）;
otherClass.DoOtherThing（）;
そのため、PosibleException（）メソッドが例外をスローした場合にDoOtherThing（）メソッドが実行されるという保証はありません。
3.「エラー戻りコード」よりも例外の遅いメカニズム。 何らかの理由で、ジョエルはこれに言及しなかったため、この議論は私によって追加されました。 なぜこれが遅いバージョンなのか、以下で分析します。
3つの引数を見ることができます（ジョエルから2つ、私から1つ:)）。 さらに、それらは非常に合理的です。
次に、このアプローチを支持する議論を見てみましょう。
1.これは、この概念の一部として考案および作成されたOOPアプローチです。 「古典的な」アプローチに対するOOPアプローチの利点を説明する必要はないと思います。誰もがよく知っています。
2.使いやすさ。 古典的な例を考えてみましょう。整数を返すSomeMethod（）クラスのメソッドがあります-エラー戻りコード、このメソッドを含むクラスから継承し、機能を拡張するためにオーバーロードします。 したがって、メソッドは値{1,2,3,4}を返すことができます。 展開後{1,2,3,4,5、...、10}。 これにより、メソッドの結果を処理するコードが増加します。 したがって、たとえば、ArgumentExceptionを使用しています。 内容を変更して、この例外の生成を追加できます。 つまり これにより、多数の戻りコードによって生じる混乱を軽減します。
3.高度な情報性。 呼び出されたメソッドでエラーが発生しました。エラーコードを取得し、ドキュメントまたはソースを調べて、このエラーの原因を探してください。 または、スタックの内容（エラーが正確に発生した場所を見つける）、ある種のクリアテキストメッセージ（開発者が新しい例外（ ""）をスローしなかった場合）、および非常に有用な他の多くのものを取得できます。開発者にとっては、非常に簡単です（詳細については、ドキュメントを参照してください）。
4.使用の原則。 原則として、これは最初の段落をエコーしますが、私はそれを別々にレンダリングすることを好みました。 スタックの奥深くにあるメソッドが例外をスローしたとします。 そして、それを呼び出すメソッドは何をすべきかを知らないので、例外はより高いレベルに渡されます。 最終的に、この例外に適切に応答するハンドラー、または「ユーザーへのメッセージ」が見つかります。 私は練習で最初のアプローチを適用しようとします。 エラーリターンコードの場合、検索でエラーを「上に」、「誰がそれを処理する必要がありますか」と操作することは非常に不便です。 あるメソッドはintを返し、別のメソッドは最終的にboolを返しますが、何が起こったかはまだわかりません。
ご覧のとおり、3。4。 さらに、開発者の観点からは、例外の使用がより便利です。
ここで、例外が遅いメカニズムである理由を説明したいと思います。例外オブジェクトが作成され、この例外を処理できるコールスタックでハンドラも検索されます。 それ自体が時間を「消費」します。 人生には自由なものは何もありません。何か（お金/時間/神経/など）を使う必要があります。
上記の比較からわかるように、例外はより便利です。 しかし、それらを乱用しないでください。 例外は、例外的な状況でのみ発生するように名前が付けられているためです！ ファイルから2バイトを読み取る場合、根本的な違いはありません。これらの順序は、この順序または逆でなければなりません。 例外をより速く作成するコードを使用しないでください。 単にあなたの場所でそれらを交換し、さらに作業を続けることができます。 この例は少し工夫されていますが、理解できると思います:)。
今、私はそれを要約する価値があると思う：
例外を使用する必要がありますが、賢明です！ 私自身、それらを使用しない状況を強調しました。最初はデータが悪く、プログラムの速度が私にとって重要な場合、何らかの理由でデータを「まっすぐにする」ことができないため、例外を使用しません。 その他の場合はすべて、例外を使用することを好みます。 私の作品では、私は一人ではないと思います。