前のトピックの親愛なる著者は、どういうわけかその瞬間を逃しました（または、私には思われましたか、それともそれ自体が暗示していますか？）その例外は、非常に実用的な問題を解決するためのツールとして発生しました- エラーが発生した場所から処理できる場所へのコントロールの転送。
そのようなタスクがどこから来たのかを明確にするための少しの歴史。 多かれ少なかれ自明ではないソフトウェア（「Hello、world」よりも複雑です）には、通常の実行を継続できないポイントが常にあります。I/ Oサブシステムが障害を生成しました。何らかの理由で、アルゴリズムの入力パラメーター、彼女は機能などが好きではありませんでした 対応方法
他のプロジェクトで使用するライブラリの作成を検討すると、状況はさらに悲しくなります。 （結果として）assert / abortまたは他の同様のハンドラを呼び出すことはできません-アプリケーション全体を終了する権利があることをどのようにして知ることができますか？ たとえば、私たちのライブラリは入力データのある種の統計を収集し、その動作のために、デバイス全体の動作が停止します。 もちろん、ペースメーカーのファームウェアを作成します。
OK、中止（）は良くありません。 バルーンのようなアプリケーションを作成したくありません-どこにでも注入すると、バルーン全体が死にました。 エラーが発生した場所と、このエラーをどう処理するかを決定する場所を分離できるテクノロジーを使用したいと考えています。 一部のアプリケーションでは反応がこれらの統計の収集の禁止になるため、他のアプリケーションではライブラリの再初期化（他のパラメーターなどを使用）になります。 上位レベルでは、エラーへの対応方法に関するより多くの情報が利用可能です。
他にどのように私たちの問題について「上」に信号を送ることができますか？ Cのerrno型のグローバル変数？ 動作しません。 戻り値？ すでに改善されていますが、新しい問題が発生します。
- プログラマは、そのような関数が呼び出されるたびに戻り値をチェックする責任を負います。
- すべてのレベルのプログラム全体がこのアプローチをサポートする必要があります（関数がライブラリから呼び出された場合、エラーが返され、呼び出し元がそれを見つけてエラーを返しましたが、より高いレベルでは混乱しました-たとえば、望ましくない）
- 呼び出しチェーンは非常によく似たブロックで構成されています。関数を呼び出してエラーをチェックし、エラーがある場合はエラー記号で終了します。 そして、それが絶えず書かれる必要があるなら-なぜそれは自動化されないのですか？
実際、ここで次の論理的なステップがとられました。 次のことを可能にするツールが言語で登場しました。
- エラー検出の場所とそれに対する反応の場所を分離するために、
- 発生した偶発的なエラーを失わないように、各関数のすべての呼び出しをチェックする義務をプログラマに課しません。
- エラーが現在のレベルで処理されていない場合-大丈夫です、上位のものがそれを行います。 おそらく彼はすでに彼女をどうするか知っているだろう、
- 言語自体によってサポートされています-この新しい方法でエラーをスローするように既存のコードを修正する必要はありません。
このツールは例外です。 これは、前述のエラー処理の概念を言語に導入した結果として当然得られます。 このツールには長所と短所があります（その使用を完全に放棄することもあります）。 さらに、「エラー状況の処理」は一般的な概念であり、「例外を使用したエラー状況の処理」はその実装の一例にすぎません。 エラー処理は、おそらくプログラマーによるもう少しのアクションを除いて、例外メカニズムを使用せずに実行することもできます。
実際、これはすべて、「何が正確に」のより良い理解が例外として機能し、「それらをどのようにどのようなケースに適用するか」をよりよく理解できるように書かれています。
PS：マイナスの例外が何を持っているかを正確にコードの例で示したいという要望もありました。 そして、どのように問題が解決されたか「エラーを処理し、同時に例外を使用しないのが便利です」（「ペースメーカー」が書かれている組み込みシステムに関連）。 しかし、それは後です。