例外の代わりにWordバグを使用しないのはなぜですか？
例外をバグと呼ぶ場合、例外ではなく、そもそもそれを単にバグと呼んではいけませんか？
コード内でそれが例外と呼ばれ、それが発生するとすぐにバグと呼ばれます。それなら、そもそもバグと呼んでみませんか？
回答やコメントをありがとうございます。
まあ、それは非常に簡単です。すべての例外がバグであるとは限りません（同様に、すべてのバグが例外として現れるとは限りません）。
バグではない例外の例として、USBドライブからファイルを読み取っていて、誰かがドライブをソケットから外した場合。これは例外を発生させます（例外をサポートするほとんどの言語では）。しかし、それはコードのバグではありません。
逆に、バグは計算エラーまたは何かとして現れることがあります。あなたはまだ答えを得ます、それはちょうど正しいものではありません。
そうは言っても、スタックの一番上まで到達する例外は、おそらくisバグです。上記のUSBの例では、その例外をキャッチして、「接続されていないため、ファイルから読み取ることができませんでした」という素敵なエラーをユーザーに提示できるはずです。か何か。それらにIOExceptionといくつかのファンキーなエラーコードを提示するだけであれば、それはバグです。しかし、例外自体はそうではありません。
単純明快、例外は（常に）バグではありません！
例外が発生すると、例外がスローされます（またはスローされるはずです）。ハードドライブに問題があり、ファイルを書き込めない場合、それはバグではありません。それはハードウェアの故障です。
バグは通常、プログラミングの不良が原因です。アプリケーションがプログラミングエラーの結果として予期しないことを行う場合、それはバグです。
彼らは同じものではありません。
バグは、ソフトウェアの意図しない動作です。ソフトウェアは想定されている動作をしません。バグは、従来のタイプミスから論理エラー、不十分な機能仕様まで、ソフトウェア開発のすべてのレベルで発生する可能性があります。
対照的にexceptionは、通常の操作から逸脱したプログラムの異常な状態、またはより具体的には、そのような状態を通知して処理するために使用される言語構造を参照できます。
例外が発生するという事実はバグの兆候である可能性がありますが、多くの場合はそうではありません。たとえば、URLからドキュメントをダウンロードしてローカルで処理することになっているアプリケーションは、リモートサーバーがダウンしているときに例外をスローする可能性があります。アプリケーションは通常の操作から逸脱しています（ドキュメントをダウンロードして処理できません）。例外を適切に処理して回復すると、バグは発生しません。
逆に、バグの存在が必ずしも例外として現れるとは限りません。アプリケーションは、入力したデータをデータベースに保存するのではなく、メッセージを表示せずに破棄する場合があります。例外はスローされませんが、それはまだバグです。
例外とバグはまったく関係ありません。もちろん、例外をスローすることもあり、それはバグを意味します。しかし、それは例外的で異常な状況を意味する場合もありますが、必ずしもプログラムのバグではありません。特に、Javaのような例外的に満足のいく言語では、すべての標準操作と犬が約5つの異なる例外をスローします。たとえば、ファイルのオープンに失敗した、ファイルの読み取りに失敗したなどです。
例外は常にバグに関連しているわけではありません。それはあなたがしていることでうまくいかないかもしれない何かと考えてください。
頭に浮かぶ例は、ドメイン名を解決するために使用されるInetAddress.getByName（）です。何かが発生してUnknownHostExceptionがスローされた場合、それは実際にはコードの問題ではありません。
自分で正当に例外を発生させることもできますが、意図的にバグが発生することはないでしょう。
ソフトウェアのバグは、コンピュータープログラムまたはシステムのエラー、欠陥、間違い、失敗、または障害を説明するために使用される一般的な用語であり、不正確または予期しない結果を生み出したり、意図しない方法で動作させたりします。ラベルのスペルミスでさえあるかもしれません。
例外はバグとは異なります。各種類の例外（アクセス違反、スタックオーバーフローなど）は、「最初のチャンス」または「2番目のチャンス」のいずれかの例外としてデバッガーに発生する可能性があります。ファーストチャンスの例外は、エラーハンドラーで適切に処理されない限り、致命的ではありません。例外が発生した時点で、セカンドチャンスの例外（デバッガーのみが処理できる）として再度発生します。
2番目のチャンスの例外を処理するデバッガーがない場合、アプリケーションはシャットダウンされます。
すべての例外はバグではありません。すべてのバグが例外であるかどうかは、議論の的となります。
例外は、アプリケーションの通常または予期されるフローの一部ではないイベントであると言えます。これらのイベントは、コードがどのように記述されているかに関係なく、バグは本質的に悪いコード（間違った計算など）の結果です。
例外を処理しないとバグになる可能性のある例を次に示します。
外部記憶装置にデータを書き込むプログラムがあるとしましょう。外部ストレージデバイスの書き込み中に、プラグが抜かれた、クラッシュした、または破壊された可能性があります（理由は何であれ）。これは例外的なケースであり、プログラミング言語が例外的な処理をサポートしているかどうかに関係なく、このイベントが原因でプログラムがクラッシュまたは誤動作した場合、それはバグです（エンドユーザーは何が起こったのかわからない可能性があります。また、非常に不快です）。 。ただし、プログラムがプロセスを正常に中止した場合は、ユーザーに通知します（つまり、例外を処理します）。これは明らかにバグではありません。
プログラミング言語で提供されているトライキャッチメカニズムは、本質的に、予期しないイベントを処理するための手段を簡単にするツールです。
概要：例外は悪い結果の証拠であり、バグは（一部の）悪い結果の原因です。問題（解決予定）は例外ではありません。問題は例外の原因です。
Resoning： A bugは、製品の設計または実装（ソフトウェアに限定されない）の欠陥です。たとえば、不適切な仕様または単純なビルドエラーのために、適切な定格のリレー（時間/感度/信頼性/容量）を使用していない。 例外は、運転中の車両の制御の喪失など、予測された（「期待された」と言っていいでしょうか？）動作からの実世界/実行時の偏差です。
明らかに、1）の例が2）の例につながる可能性があるため、バグが例外を引き起こす可能性があります。しかし、すべての例外がバグによって引き起こされるとは限りません。たとえば、オペレーターがストロークしたために車両の制御が失われるなどです。
バウンティのためにこの質問が再開されたので、2003年のCUJの記事「例外かバグか？」について触れましょう。OPの質問に正確に対応しているようです。
基本的に、記事では「バグ」と「例外」（例を示す）という用語を定義し、それぞれに対処するための戦略を提案します。
この記事では、バグを「処理する」のではなく、アサーションでフラグを立てることを提案しています。対照的に、真の例外はコードによる処理（例外のスロー/キャッチ）を必要とします。
重要な点は、バグは例外よりも正確なopposite戦略を必要とすることです。
前述の記事は、Dr.Dobbの次の場所から入手できます。 http://www.drdobbs.com/an-exception-or-a-bug/184401686