プログラミング言語でエラーが「例外」と命名されているのに「エラー」と命名されていないのはなぜですか？

私は実際にかなり長い間それについて考えてきました。私は英語を母国語とする人ではありませんが、それでも何年もプログラミングの経験があり、常に私に尋ねました。なぜエラーとしてではなく例外として名前が付けられているのですか？

のPageNotFoundError代わりになりPageNotFoundExceptionます。

エラーである必要はまったくありません。ページが存在しないという事実は、実際のエラーではなく、単に興味深い事実である可能性があります。 それらはほとんど常にエラーとして使用されるようです、私は認めます。ただし、ループから抜け出したり、文字列が有効な数値ではないことを知らせるために使用されることもあります。これらは、かなり通常の戻り値の一部として、膨大な量の有用なデータを保持して返すために使用できます。（一部の言語は例外があり、少し遅いです。その場合、頻繁にスローするのは悪い考えです。）理論上は、例外は単に「通常のリターンを行わず、興味のある人が見つかるまでコールスタックを上げる」という意味です。これで。」

NULLポインター例外であっても、あまり意味がないかもしれません。他の人のコードを呼び出してから、Nullポインター例外をキャッチします。これは、爆発する傾向があることがわかっているためです。エラーの原因を示すメッセージを出力し、処理を続行します。

例外のメカニズムは、常にエラーを通知するために使用されるわけではありません。エラーを含む、処理するために別のコードパスを必要とする通常の状況から例外がスローされます。たとえば、存在しないファイルの名前を指定するユーザー、または数値フィールドに数字の代わりに文字を入力するユーザーは、特別な処理が必要な例外的な状況ですが、これらはエラーではありません。

Javaなどの一部のプログラミング環境では、Error「真のエラー」を報告するための特別なオブジェクトが提供されます。これは、合理的なアプリケーションが処理を試みてはならない状況です。これらのオブジェクトは、例外の配信に使用されるのと同じメカニズムを使用して配信されますが、回復不能な状況のシグナルという特別な意味を持ちます。

私はその起源について語源的な研究をしていませんが、「エラー」という用語を使用することがすべての状況で正確であるとは限らないことを理解できます。また、ほぼSharePointMasterが述べたように、エラーとスローされた例外を別々のエンティティとして考えることをお勧めします。

高レベルのプログラミング言語を使用している場合、例外は常にエラーによって引き起こされると想定するのは理にかなっていますが、それでも例外は常にエラーの結果ではないというdasblinkenlightにも同意します。例えば、私は例外を使用してスレッドを共同で終了します。

「例外」という用語を初めて目にしたのは、80386アセンブリマニュアルでした。私はそれを見たとき、私にとって即座に自然に見えたことを覚えています。これを呼び出すと、アセンブリにエラーがないため、エラーは正しくありません。プロセッサが処理できない単純な条件があります（それがエラーである場合-プログラマ、ユーザー、またはシステムからの場合-プロセッサは完全に不可知です）。インテルが本当にこの用語を生み出したかどうかはわかりませんが、多分...

一般的に、out_of_range例外は、C ++の例外のように、正しくないが回復できるイベントに名前を付けるために使用されます。これは、存在しないベクトルまたは配列の要素にアクセスしたときにスローされます。明らかにそのようなイベントは正しくありませんが、プログラム全体がクラッシュすることを意味するものではありません。

一方、エラーは通常、すべてをクラッシュさせるものに名前を付けるために使用されます。スタックオーバーフローのようなものは、プログラムが内部で処理できないためプログラムを終了するイベントの例です。つまり、エラーは重大であり、例外は比較的軽微です。

これはエラー処理の「進化」と関係があると思います。C / C ++（例外処理が追加される前）言語では、関数が失敗した場合、通知する唯一の方法は戻り値（HRESULTwin32など）でした。したがって、通常、各関数呼び出しの終了コードをキャッチしてチェックを行います。このアプローチにより、コードがより複雑になります。そして多くの場合、開発者は怠theseからこれらのチェックを追加することを避けます。

例外処理の導入により、開発者にはエラーを発生させる2つのオプションがありました。そのため、「例外」という言葉は、エラーを「終了ステータス」エラーと区別するために使用されていました。しばらくすると、コードを読みやすく、保守しやすくなり、エラー処理ロジックを持つことができる単一の場所があるため、例外処理はエラーを伝播する一般的な方法になりました。

Pythonでは、ABCErrorとして名前が付けられます。例：KeyError、IndexError

http://docs.python.org/library/exceptions.html

だから、使用する言語に依存すると思います。

エラーが発生すると、システムまたは現在実行中のアプリケーションのいずれかが、エラーに関する情報を含む例外をスローして報告します。スローされると、例外はアプリケーションまたはデフォルトの例外ハンドラーによって処理されます。

エラーはエラーの詳細を示す例外を調整するため、すべてが必ずしも理にかなっている場合は例外であるわけではありません;）、たとえば、実装されていない例外はエラーではなく例外を調整します。

http://msdn.microsoft.com/en-us/library/system.exception.aspx

iOS / Macプログラミングでは、単一言語で例外とエラーの両方があります。

少なくともその環境では、例外は「回復不能」ですが、エラーは「回復可能」です。

例えば：

• 10個のアイテムを持つ配列があり、インデックス30でアイテムにアクセスしようとすると、例外になります。プログラミングを間違えました。
• URLをダウンロードしようとしてもインターネットに接続できない場合、それは予想されることであり、何らかのメッセージをユーザーに提示する必要があります。

通常、例外はアプリをクラッシュさせますが、エラーは通常nil、エラーオブジェクト（参照メソッドパラメーターとして返されます）を返します。try / catch / finallyブロックで例外をキャッチできますが、この言語機能を使用しないことをお勧めします-何らかの方法で例外から回復できる場合は、例外をまったくスローしないでください（返す必要があります）代わりにエラーオブジェクト）。

エラーは、プログラムの実行中になくなって間違って持っているものです。多くの場合、これは例外を発生させることで対処されますが、

• プログラマーが例外を発生させてエラーを処理することを強制するものはありません。
• エラーが発生した場合にのみプログラマーに例外を発生させることはありません。

エラーはセマンティックな概念です。それはプログラマーまたはユーザーによって適用されます。プログラマーまたはユーザーは、期待してプログラムにアクセスし、期待と現実の違いを説明します。ルーチンがエラー状態にあるかどうかを判断できるのは人だけです。

例外は構文上の概念です。それはプログラム自体にあるものであり、そのプログラムが何をすべきかについての誰の期待にも依存しません。ルーチンは、誰が何を考えているかに関係なく、例外を発生させるか、発生させません。

例外とエラーは異なります。

例外は、ファイルを開こうとすると存在しないなど、プログラムが克服できる状況であり、エラーは、ディスク障害やRAM障害など、プログラムが何もできない状況です。

例外の発生と処理は制御フロー機能であり、例外の名前は意図した使用法に従う必要があります。コードとAPIの設計者は、適切で一貫性のある命名スキームを見つける必要があります。

あなたの質問への答えは次のとおりです。それは文脈と視点に依存します。

例外はエラーの一般化として発展しました。例外メカニズムを含む最初のプログラミング言語は、 1970年代初頭にLispのでした。ガブリエルとスティールによる言語進化のパターンに良い要約があります。例外（まだ例外と呼ばれていない）は、エラーが発生した場合にプログラムの動作を指定する必要から生じました。1つの可能性はプログラムを停止することですが、これは常に役立つとは限りません。Lispの実装では、従来、エラーが発生するとデバッガーに入る方法がありましたが、プログラマーはプログラムにエラー処理を含めることを望んでいました。したがって、1960年代のLisp実装には、「これを実行し、エラーが発生した場合は代わりに実行する」という方法がありました。もともとエラーは原始関数から発生していましたが、プログラマはプログラムの一部をスキップしてエラーハンドラにジャンプするために意図的にエラーをトリガーすると便利だと感じました。

1972年には、Lispでの例外処理の現代的な形はのMacLispに登場：throwとcatch。ソフトウェア保全グループは含めて早期のLispの実装、上の材料の多くを示していますデビッド・ムーンのMacLispリファレンスマニュアル改訂0。プリミティブcatchおよびthrow§5.3p.43に文書化されています。

catch構造化された非ローカル出口を実行するためのLISP関数です。(catch x)評価しx、その値を返すは、場合の評価時のことを除いてx (throw y)評価されるべきで、catchすぐに戻るyさらになし評価しますx。

catchネストされたキャッチを区別するためのタグとして使用される、評価されないecond引数とともに使用することもできます。（…）

throwcatch構造化された非ローカル終了メカニズムとして使用されます。

(throw x)評価xし、値を最新の値に戻しcatchます。

(throw x <tag>)の値xを、catchラベル付き<tag>またはラベルなしの最新のラベルに戻します。

焦点は非ローカル制御フローにあります。これはgoto（上向きのみのgoto）の形式で、ジャンプとも呼ばれます。比metaは、プログラムの一部が例外ハンドラーに戻るために値をスローし、例外ハンドラーがその値をキャッチして返すことです。

今日のほとんどのプログラミング言語は、タグと値を例外オブジェクトにパックし、キャッチメカニズムと処理メカニズムを組み合わせています。

例外は必ずしもエラーではありません。これらは、コードのブロックと周囲のブロックを終了し、例外のハンドラーに到達するまでエスケープする方法です。そのようなことが直感的な意味で「エラー」と見なされるかどうかは主観的です。

一部の言語では、「エラー」と「例外」という用語を区別しています。たとえば、一部のLisp方言ではthrow、例外（ユーザーの制御フロー、何かが「間違った」ことを示さない方法で非ローカル出口を実行することを意味する）とsignalエラー（これは、何かが「間違った」状態になり、デバッグイベントがトリガーされる場合があります。

異なるプログラミング言語の実装では、解釈が異なります。dasblinkenlightが言ったように、それはJavaの観点から見たエラーと例外の境界を持つことです。多くのプログラミング言語では、例外は違反であり、これを処理するかバブルアップして、可能な限り最高のコードモジュールに渡すことができます。通常、エラーは、言語のランタイムコンテナが処理する状況です（多くの場合、実行が停止するだけです）。

エラーは常にエラーです。例外は、現在のコンテキストのエラーです。つまり、例外はコンテキスト依存です。例外の例は、ascii「a」を整数「1」に追加することです。エラーは、「+！」のような未定義の演算子を使用するようなものです。ほとんどの言語で。

一部の言語では、本当にやりたいことがある場合に、状況から抜け出す方法を定義できます。