例外の代わりにバグという言葉を使用しないのはなぜですか？[閉まっている]

例外をバグと呼ぶ場合、そもそも例外ではなく単にバグと呼ぶだけではどうでしょうか？

コード内で例外と呼ばれ、発生するとすぐにバグと呼ばれます。それでは、そもそもそれをバグと呼んでみませんか？

回答やコメントをありがとうございます。

まあ、それは非常に簡単です：すべての例外がバグであるわけではありません（同様に、すべてのバグが例外として現れるわけではありません）。

バグではない例外の例として、USBドライブからファイルを読み込んでいて、誰かがソケットからドライブをヤンクした場合。これにより、例外が発生します（つまり、例外をサポートするほとんどの言語で）。しかし、それはコードのバグではありません。

逆に、バグは、計算エラーなどとして現れる場合があります。あなたはまだ答えを得ます、それはちょうど正しいものではありません。

そうは言っても、スタックの最上位に到達する例外はおそらくバグです。上記の私のUSBの例では、その例外をキャッチして、「接続されていないためファイルから読み取ることができませんでした」という素晴らしいエラーをユーザーに表示できるはずです。か何か。あなただけでそれらを提示した場合IOException、いくつかのファンキーなエラーコード、そして、それはだバグ。しかし、例外自体はそうではありません。

単純明快な例外は、（常に）バグではありません！

例外が発生すると例外がスローされます（またはスローされるはずです）。ハードドライブに問題があり、ファイルを書き込めない場合、それはバグではありません。それはハードウェアの故障です。

バグは一般に、不適切なプログラミングの結果です。アプリケーションがプログラミングエラーの結果として予期されないことを行う場合、それはバグです。

それらは同じものではありません。

バグは、ソフトウェアの一部の意図しない動作です：ソフトウェアは、行うことになっている何をしません。バグは、単純な古いタイプミスから論理エラー、不適切な機能仕様に至るまで、ソフトウェア開発のすべてのレベルで存続できます。

例外は、対照的に、信号とそのような条件を処理するために使用される言語構造に、より具体的には、正常な動作から逸脱、プログラムの異常な状態のいずれかを指す、またはすることができます。

例外が発生するという事実はバグの兆候である可能性がありますが、多くの場合そうではありません。たとえば、URLからドキュメントをダウンロードしてローカルで処理することになっているアプリケーションは、リモートサーバーがダウンしているときに例外をスローする場合があります。アプリケーションは通常の動作から外れています例外を適切に処理して回復すると、バグはありません。

逆に、バグの存在は必ずしも例外として現れるとは限りません。アプリケーションは、入力したデータをデータベースに保存する代わりに、静かに破棄する場合があります。例外はスローされませんが、それでもバグです。

例外とバグはまったく関連していません。確かに、例外をスローすることもありますが、これはバグを意味します。ただし、例外的な異常な状況を意味する場合もありますが、これは必ずしもプログラムのバグではありません。特に、Javaのような例外対応言語では、すべての標準操作とその犬が約5つの異なる例外をスローします。たとえば、ファイルのオープンに失敗した、ファイルの読み取りに失敗したなどです。

例外は必ずしもバグ関連ではありません。あなたがしていることでうまくいかないものと考えてください。

思い浮かぶ例は、ドメイン名を解決するために使用されるInetAddress.getByName（）です。何かが発生してUnknownHostExceptionがスローされた場合、実際にはコードの問題ではありません。

ソフトウェアバグは、コンピュータプログラムまたはシステムのエラー、欠陥、間違い、失敗、または障害を説明するために使用される一般的な用語であり、不正確または予期しない結果を生成したり、意図しない動作をさせたりします。ラベルのスペルミスである場合もあります。

例外はバグとは異なります。各種類の例外（アクセス違反、スタックオーバーフローなど）は、「最初のチャンス」または「2回目のチャンス」の例外としてデバッガに発生する可能性があります。定義上、エラーハンドラーで適切に処理されない限り、最初のチャンスの例外は致命的ではありません。

セカンドチャンス例外を処理するデバッガーがない場合、アプリケーションはシャットダウンされます。

自分で合法的に例外を発生させる可能性がありますが、意図的にバグを導入することはできません。

すべての例外はバグではありません。すべてのバグが例外であるかどうかという議論のトピックになります。

例外は、アプリケーションの通常のフローまたは予想されるフローの一部ではないイベントであると言えます。これらのイベントは、バグが本質的に悪いコード（間違った計算など）の結果である場合に、コードがどのように記述されているかには依存しません。

例外を処理しないことがバグになる可能性がある例を次に示します。

外部ストレージデバイスにデータを書き込むプログラムがあると仮定しましょう。外部ストレージデバイスへの書き込み中に、プラグが抜かれたり、クラッシュしたり、破壊されたりする可能性があります（何らかの理由で）。これは例外的なケースであり、プログラミング言語が例外的な処理をサポートしているかどうかに関係なく、プログラムがこのイベントのためにクラッシュまたは誤動作する場合、それはバグです（エンドユーザーは何が起こったのか分からないかもしれません。 。ただし、プログラムがプロセスを正常に中止した場合、ユーザーに通知する（つまり例外を処理する）ことは明らかにバグではありません。

プログラミングプログラミング言語が提供するtry catchメカニズムは、本質的に、予期しないイベントを処理する方法を容易にするツールです。

概要：例外は悪い結果の証拠であり、バグは悪い結果の原因の一部です。（解決される）問題は例外ではなく、問題が例外の原因です。

Resoning：バグ、製品の設計や実装の欠陥である（ソフトウェアに限定されません）。たとえば、仕様の誤りまたは単純なビルドエラーのために、適切な定格のリレー（時間/感度/信頼性/容量）を使用していません。例外は（私はあえて言う「期待」？）行動を、例えば、車両の制御の損失を運転しながら、予測から現実の世界/実行時間偏差です。

1）の例が2）の例につながる可能性があるため、明らかにバグが例外を引き起こす可能性があります。しかし、すべての例外がバグによって引き起こされるわけではありません。たとえば、オペレーターが脳卒中を起こしたために車両の制御が失われるなどです。

この質問は賞金のために再開されたので、2003年の「例外かバグか？」というCUJの記事に言及しましょう。これはOPの質問に正確に対処しているようです。

基本的に、この記事では「バグ」と「例外」という用語を定義し（例を挙げて）、それぞれに対処するための戦略を提案しています。

この記事では、バグを「処理」するのではなく、アサーションでフラグを立てることを提案しています。対照的に、真の例外はコードを介して処理する必要があります（例外をスロー/キャッチする可能性があります）。

主なポイントは、バグが正反対を必要とすることです例外戦略を。

前述の記事は、Dr.Dobb'sから入手できます。http：//www.drdobbs.com/an-exception-or-a-bug/184401686