プログラミング言語でエラーの名前が「例外」ではなく「エラー」ではないのはなぜですか？
それについてはかなり前から考えていました。私自身は英語のネイティブスピーカーではありませんが、それでも長年のプログラミング経験があり、いつもこれを尋ねてきました。エラーであるため、例外ではなくエラーとして指定されているのはなぜですか。
PageNotFoundErrorの代わりにPageNotFoundExceptionにすることもできます。
エラーである必要はありません。ページが存在しないという事実は、実際のエラーではなく興味深い事実である可能性があります。それらはほとんど常にエラーとして使用されているようです。私は認めます。ただし、ループから抜け出すために使用したり、文字列が有効な数値ではないことを知らせたりすることがあります。それらは、非常に通常のリターンの一部として、膨大な量の有用なデータを保持して返すために使用できます。 （一部の言語は例外があり、少し遅いです。その場合、頻繁にスローすることは悪い考えです。）理論的には、例外は単に「通常のリターンを行わないで、興味がある人が見つかるまでコールスタックを上る」ことを意味します。これで」
Nullポインタ例外であっても、あまり意味がないかもしれません。誰か他の人のコードを呼び出して、それが爆発しがちであることがわかっているので、nullポインター例外をキャッチし、それが誰の過失であるかを示すメッセージを出力し、続けてジョブを実行します。
例外のメカニズムは、エラーを通知するために常に使用されるわけではありません。例外は、エラーを含め、処理に別のコードパスが必要な通常の状況以外でスローされます。たとえば、存在しないファイルの名前を提供したり、数値フィールドに数字ではなく文字を入力したりするユーザーは、特別な処理を必要とする例外的な状況ですが、これらはエラーではありません。
Javaなどの一部のプログラミング環境では、特別な Error オブジェクトが提供され、「真のエラー」を報告します。これらのオブジェクトは、例外の配信に使用されるのと同じメカニズムを使用して配信されますが、それらには回復不可能な状況のシグナルという特別な意味があります。
その起源についての語源的な調査はありませんが、「エラー」という用語の使用がすべての状況で正確であるとは限らないことは理解できます。また、mostSharepointMasterで述べたように、エラーとスローされた例外は別々のエンティティとして考えるのがよいでしょう。
高水準プログラミング言語を使用している場合、例外は常にエラーによって引き起こされると想定するのが理にかなっていますが、それでも例外が常にエラーの結果であるとは限らないというdasblinkenlightにも同意します。たとえば、例外を使用して共同でスレッドを終了します。
「例外」という用語を初めて目にしたのは、80386アセンブリマニュアルにありました。見たとき、それは一瞬で自然に見えたのを覚えています。アセンブリにエラーがないため、エラーを呼び出すことは正しくありません。プロセッサが処理できない条件があります（それがエラーである場合-プログラマー、ユーザー、またはシステムから-まあ、プロセッサはそれに完全に依存していません）。インテルがこの用語を本当に生み出したかどうかはわかりませんが、多分...
一般に、Exceptionは、正しくないが回復可能なイベントを指定するために使用されます。たとえば、C++のout_of_range例外は、存在しないベクトルまたは配列の要素にアクセスするとスローされます。明らかにそのようなイベントは正しくありませんが、それが起こっても、プログラム全体がクラッシュするわけではありません。
一方、エラーは通常、すべてをクラッシュさせるものに名前を付けるために使用されます。スタックオーバーフローのようなものは、プログラムが内部で処理できないためプログラムを終了する必要があるイベントの例です。つまり、エラーは重大ですが、例外は比較的軽微です。
これは、エラー処理の「進化」にもっと関係があると思います。 C/C++（例外処理が追加される前の）言語では、関数が失敗した場合、通知する唯一の方法は戻り値（例：win32のHRESULT）でした。そのため、通常は、各関数呼び出しの終了コードをキャッチしてチェックを行います。この方法では、コードが煩雑になります。そして多くの場合、開発者は怠惰からこれらのチェックを追加することを避けます。
例外処理の導入により、開発者は2つのオプションを使用してエラーを発生させることができました。したがって、「例外」という単語は、エラーを「終了ステータス」エラーと区別するために使用されました。しばらくすると、コードの読み取りと保守がはるかに簡単になり、エラー処理ロジックを1か所に置くことができるため、例外処理はエラーを伝播する一般的な方法になりました。
Pythonでは、ABCErrorという名前になります。例：KeyError、IndexError
http://docs.python.org/library/exceptions.html
使用する言語に依存すると思います。
エラーが発生すると、システムまたは現在実行中のアプリケーションのいずれかが、エラーに関する情報を含む例外をスローしてエラーを報告します。スローされると、例外はアプリケーションまたはデフォルトの例外ハンドラーによって処理されます。
エラーはエラーの詳細を示す例外をスローします。したがって、それが理にかなっている場合、すべてが例外であるエラーではありません;）たとえば、実装されていない例外はエラーではなく、例外をスローします。
http://msdn.Microsoft.com/en-us/library/system.exception.aspx
例外とエラーは異なります。
例外は、ファイルを開こうとしたが存在しないなど、プログラムが克服できる状況です。エラーは、ディスク障害やRAM障害など、プログラムが何もできない状況です。 。
errorは、プログラムの実行で問題が発生したものです。多くの場合、これはexceptionを上げることで処理されますが、
- 例外を発生させることによってプログラマにエラーを処理させることは何もありません。
- エラーが発生した場合にのみプログラマに例外を発生させることはありません。
エラーはセマンティックの概念です。これは、期待を持ってプログラムにアクセスするプログラマまたはユーザーが、期待と現実の違いを説明するために適用されます。ルーチンがエラー状態であるかどうかを言うことができるのは人だけです。
例外は構文の概念です。これはプログラム自体に含まれるものであり、そのプログラムが行うことになっていることについての誰かの期待とは無関係です。ルーチンは、誰かが何を考えているかに関係なく、例外を発生させるか発生させません。
例外はエラーの一般化として発展しました。 例外メカニズムを組み込んだ最初のプログラミング言語 は、1970年代初頭のLISPでした。 A Pattern of Language Evolutionby Gabriel and Steele に良い要約があります。例外（まだ例外とは呼ばれていませんでした）は、エラーが発生した場合のプログラムの動作を指定する必要から生じました。 1つの可能性はプログラムを停止することですが、これが常に役立つとは限りません。 LISPの実装には、伝統的にエラー時にデバッガーに入る方法がありましたが、プログラマーはプログラムにエラー処理を含めたいと思ったことがあります。したがって、1960年代のLISP実装には、「これを行い、エラーが発生した場合は代わりにそれを行う」という方法がありました。もともとエラーはプリミティブ関数から発生していましたが、プログラマーは、プログラムの一部をスキップしてエラーハンドラーにジャンプするために、意図的にエラーをトリガーするのが便利であると考えました。
1972年に、LISPの最新の例外処理形式がMacLispに登場しました：throwとcatch。 Software Preservation Group には、 David MoonによるMACLISPリファレンスマニュアルリビジョン を含む、初期のLISP実装に関する多くの資料がリストされています。プリミティブcatchおよびthrowは、§5.3p.43に記載されています。
catchは、構造化された非ローカル出口を実行するためのLISP関数です。(catch x)は、xを評価してその値を返します。ただし、xの評価中に(throw y)を評価する必要がある場合、catchは、yをさらに評価せずに、すぐにxを返します。
catchは、ネストされたキャッチを区別するためのタグとして使用される、評価されないecond引数とともに使用することもできます。 （…）
throwは、構造化された非ローカル終了メカニズムとしてcatchとともに使用されます。
(throw x)はxを評価し、値を最新のcatchに戻します。
(throw x <tag>)は、xの値を、<tag>でラベル付けされた、またはラベル付けされていない最新のcatchに戻します。
nonlocal制御フローに焦点を当てています。 goto（上向きのみのgoto）の一種で、jumpとも呼ばれます。メタファーは、プログラムの一部throws例外ハンドラーに返す値、および例外ハンドラーです。その値をキャッチして返します。
今日のほとんどのプログラミング言語は、タグと値を例外オブジェクトにパックし、キャッチメカニズムと処理メカニズムを組み合わせています。
例外は必ずしもエラーではありません。これらは、コードのブロックと周囲のブロックを終了し、例外のハンドラーに到達するまでエスケープする方法です。そのようなことが直感的な意味での「エラー」と見なされるかどうかは主観的です。
一部の言語では、「エラー」と「例外」という用語を区別しています。たとえば、一部のLISP方言には、例外を発生させるthrow（ユーザーに対して制御フロー、「何かが間違っている」ことを示さない方法で非ローカル終了を実行することを意図）とエラーを発生させるsignal（両方何かが「間違った」状態になり、デバッグイベントをトリガーする可能性があることを示します）。
例外の発生と処理は制御フロー機能であり、例外の名前は意図された使用法に従う必要があります。コードとAPIの設計者は、優れた一貫性のある命名方式を見つける必要があります。
だからあなたの質問への答えは：それは文脈と視点に依存します。
IOS/Macプログラミングでは、1つの言語で例外とエラーの両方が発生します。
少なくともその環境では、例外は「回復不能」ですが、エラーは「回復可能」です。
例えば：
- 10項目の配列があり、インデックス30の項目にアクセスしようとすると、例外になります。プログラミングを間違えました。
- uRLをダウンロードしようとしたがインターネットに接続されていない場合、これは予想されることであり、ユーザーに何らかのメッセージを表示する必要があります。
例外は通常アプリをクラッシュさせますが、エラーは通常nilとエラーオブジェクト（参照メソッドパラメータとして返される）を返します。例外はtry/catch/finallyブロックでキャッチできますが、この言語機能を使用しないことをお勧めします。何らかの方法で例外から回復できる場合は、例外をスローするべきではありません（返す必要があります）代わりにエラーオブジェクト）。