「バグ」の定義について

Kokudoriさんという方が、例外 Advent Calendar 2014という大変興味深いアドベントカレンダーを書き始めていらっしゃいます。
自分はJavaで例外機構を使ってはいるものの、その理論については特に考えたことは無いので、とても面白そうです。

その1日目ですが、「バグ」という言葉について、「必ず起きる失敗はバグ」という定義をしていました。（追記：後述しますが、バグという言葉を定義していると思ったのが勘違いだったようです）
これは今まで自分が聞いたことがない定義だったので、びっくりしました。自分が思っていた定義は以下のようなものです。

• アプリケーションが仕様書に沿った挙動をしない場合は「（製造）バグ」
• 設計書が上位の設計書（最終的には、顧客が本来望んでいた動作）を満たしていない場合は「仕様バグ」

つまり、どんなに変だと思う挙動や処理失敗が起きたとしても、仕様書に載っている動作であれば（製造）バグではありません。

プログラムを実行した際に起こる「失敗」は、予測可能なものと不可能なものがあります。
例えばファイルを読み込む場合、そのファイルが無い可能性があります（これは予測可能でしょう）。ファイルが無かったらどうするのかは、設計書に書くべきことです。ファイルが無かった場合に設計書に書かれた動作が行われれば、それはバグではありません。（設計書と異なる動きをしたら、バグです）
一方、設計書にファイルが無かった場合の動作が書かれていなかったら。ファイルの読み込みは失敗し、設計書に書かれている動作（ファイル読み込み）は出来ませんね。これを製造バグと呼ぶか「設計書にそもそも挙動を書いておけよ」という意味で仕様バグと呼ぶかは悩ましいですが、いずれにしても、この設計書にはファイルが読み込める前提でしか書かれていないので、それが実現できておらず、バグと言えると思います。

逆に言えば、設計書は、予測可能な失敗に対しては どういう動作をするか書かなければなりません。
そこから漏れて実行時に起きる失敗（つまり予測できなかった失敗）がバグです。
（想定外の入力があった場合の動作を「未定義」あるいは「不定」と書いておけば、そういう入力に対して何が起きても“仕様通り”となりますｗ） 

ちなみに、予測可能な失敗、というか設計書に対処方法が書ける失敗は、自分は「エラー」と呼びます。
エラーに対する対処ロジックは、エラー処理、あるいは異常系の処理と呼びます。
バグに対しては（そもそも予測できないので）設計書に対処方法を書けません。（書けるのであれば、それはバグではなく、エラーです）

---

Kokudoriさんが書かれている「バグにソフトウェアが対応すべき責任は無い」というのは理解できます。
プログラム自身がバグに対応する（バグを修復する）ことは無い、という意味だと思います。
自分のバグの定義では、責任が無いというより、そもそもバグは設計書に対処方法を書けないので、バグに対する処理をプログラミングすることも出来ない、ということですが。

ファイルが無かった場合に「大抵の場合これはバグとは呼ばれません」というのは、自分の定義に従えば、「大抵の場合、ファイルが無かった場合の動作が設計書に書かれているので、バグとは呼ばれない」です。前述の通り、設計書に記述されていなかったら、バグと呼びます。

---

失敗の発生頻度によってバグか例外かを分ける考え方は初めて聞いただけに、自分の頭ではいまいちピンときていません。
なので、とりあえず、自分がどう考えているかだけ書いてみました。

追記：Kokudoriさんからお返事をいただきました→Gist

---

追記2：
「必ず起きる失敗はバグという名前で呼ばれています」という文章の意味を自分が勘違いしていたようです。
これを、「必ず起きる失敗≡バグ」、つまりバグの定義「バグとは、必ず起きる失敗のことである」と解釈したのですが、そうではなく、「（どんな条件下でも常に）必ず起きる失敗は、バグである（バグ以外の何者でもない）」というニュアンスだったようです。
（で、バグは例外処理の対象外である（別のレイヤーに属している）、という分類になる）