5. 結び
所詮nullかどうかを確認するだけのことだが、
人間はそれを完璧にはこなせない。
「nullチェック忘れ」を克服するため、nullオブジェクトパターン、
選択型（option type）、null許容型、コンパイラの静的解析など、
様々な工夫を見てきた。
しかし、それらの複雑さを導入するコストは、
効果に見合うものであると言い切れるだろうか。
書籍 Software Tools [1] には、エラー処理について次のような記述がある:
Error checking interferes with readability, no question about it, but it is necessary. With the best of languages, error checking obscures the main flow of events because the checks themselves impose a structure on the code which is different from that which expresses the basic job to be done. Programs written from the start with well thought out error checks, however, prove to be more reliable and live longer than those where the error checking is pasted on as an afterthought.
要約:
- エラーチェックは可読性を間違いなく悪くするが、それは必要なことだ
- エラーチェックそれ自体が、通常の処理が表す構造とは異なる構造をコードに強いるので、 最良の言語をもってしても、エラーチェックは通常のフローを分かりにくくする
- 最初からエラーチェックを考慮して書いたプログラムは、 後付けでエラーチェックを書き足したプログラムよりも、信頼できるし、長生きする
エラーチェックをnullチェックに置き換えてみると、 40年以上前から状況はあまり変わっていないようだ。 もちろん、例外のスロー、キャッチのような仕組みで、 通常の処理と例外処理の構造を分離できるようになった言語は多い。 しかし、通常の処理として戻り値をチェックし、 その値の種類によって異なる処理を実行するという点では、 何も変わっていない。
また、プログラミング言語のnull安全性として、 言語の途中のバージョンから仕掛けを追加したものと、 最初から仕掛けが備わっているものでは、使い勝手にかなり大きな差がある。 生粋のnull安全性は後付けのそれとは別格である。 [1] の表現を真似させてもらうと、 「最初からnull安全性を考慮して設計されたプログラミング言語は、 後付けで追加されたものよりも、信頼できるし、長生きする」だろう。
最後に、null安全性に関する議論は、昔のgotoのようである。
gotoを排除すればとにかく良くなるらしい、
gotoが無い代わりにラベル付きbreakというgotoの亡霊を登場させる、
などなど。
gotoを隠しても、その概念は消えない。
nullも同じである。値が0個または1個である、
という状況への対応は、nullがあろうがなかろうが、存在し続ける。