剛剛發表了《什么是契約》一文，突然發現自己通篇都在寫理論，沒有實例來證明。所以趕快補充一個反面案例——C++ IOStream。說是反面，不是因為IOStream庫設計得不精彩（恰恰相反，你很難找到比IOStream設計更為精彩的C++庫了），而是想展示一下，在沒有契約概念的思想體系里，組件設計將為權責不清的錯誤處理付出多大的代價。
大家知道，C++ IOStream庫非常經典，最先起源于Bjarne Stroustrup的Stream庫，之后經過Jerry Schwartz、Martin Carroll、Andy Koenig等人的改進，成為IOStream庫，并被并入Bell實驗室發行的USD C++庫中，廣為傳播。后來USD庫逐漸消亡了，而IOStream由于獲得廣泛應用，得以幸免，并以新的形式被置于標準庫中。
對于錯誤處理，當IOStream庫誕生的時候（大約1985－1987），C++還沒有異常機制。因此，Jerry Schwartz發明了這樣一套錯誤處理機制：
例1：經典的IOStream錯誤處理：
ifstream ifs("filename.txt", ios::in);
if (!ifs) { // 這里實施了向void*轉型的操作
// 文件打開失敗，實施錯誤處理
}
先測試文件是否打開，再實施具體操作，這是經典IOStream庫的一個慣用法（idiom)。
我們現在設想用戶沒有很好地執行這個idiom：
int val;
ifstream ifs("filename.txt", ios::in);
ifs >> val;
如果filename.txt打開失敗，會發生什么情況？
如果哪位還有當年的Borland C++ 3.1，可以試著測試一下。我估計是什么也不發生，或者說，程序處于極端危險的“undefined behavior”狀態。
這種情況對C++庫開發者來說是不能接受的。因此，盡管問題的出現是由于用戶的錯誤（他們沒有正確地測試流狀態），但是由于非契約思想體系下的權責不清，IOStream庫的開發者開始追求足以應對用戶錯誤的組件開發技術。由此，IOStream開始在一個方向上被拖入了復雜性的泥潭之中。
我們看看標準庫中的對付這種情況采用什么辦法。標準IOStream有一個成員函數叫做exceptions()，專門用來幫助程序員切換異常模式。缺省情況下，異常觸發并沒有打開，所以情形跟經典IOStream庫相同。如果你在操作IOStream之前如下調用：
strm.exceptions(std::ios::eofbit | std::ios::failbit |
std::ios::badbit);
則當流不處于good狀態時，執行類似 strm >> val；這樣的操作時，將會拋出異常。
這樣做看起來不錯，是嗎？
我覺得不是。請恕我C++標準的異議，這是我第一次正式對C++標準中的設計提出異議。
這種設計帶來的缺點，首先是復雜。在Nicolai Josuttis的The C++ Standard Library中，對這個機制整整用了5頁紙來解釋，還意猶未盡。復雜的設計必然帶來復雜的使用規則，而面對復雜的使用規則，用戶是可以投票的，那就是你做你的，我不用！讀這篇帖子的人，誰在實際項目中使用過exceptions()？事實上，我個人是害怕exception甚于害怕undefined behavior。
而對于用戶來說，你可以不用，卻不得不為對它付出運行性能和空間的代價。諸位有興趣，不妨追蹤一個IOStream功能的實現，看看為了支持這個異常，IOStream庫的設計這耗費了多大的心力，而你的CPU又為此耗費了多少clock。
缺點之二，是異常本身的問題——即使你抓到了異常，又當如何？程序可能已經完全離開了發生異常時的執行環境，也許你連異常為什么發生都搞不清楚，談何處理？也無非就是通知用戶一聲：“我完了，因為一個異常發生在XXXXXXXX處，你要報告的話給我發Email吧。” 是啊，你還能做什么呢？
我們試著用契約觀點來分析這一狀況，如果說“先測試，再使用”在傳統上是一個idiom，那么在contract思想里上升為一個契約。對于C++來說，應該將“流處于good狀態”作為一個契約，在每一個成員函數里進行檢查。甚至你還可以設置一個調試期標志，專門用來核查用戶是否檢查過流狀態。在必要的操作進行之前，你可以先用斷言檢查用戶是否檢查過流狀態，滿足了契約。這樣一來，在契約之下，用戶將被迫以正確的方式使用組件，從而大幅度簡化組件開發的復雜度。
再來考慮異常。如果真正發生了異常，在Eiffel中提供了retry機制。Bjarne Stroustrup說過，retry可以做到，但是往往沒有意義。為什么沒有意義呢？因為C++中沒有契約的思想，異常的產生可能根本就是程序員的bug。在這種情況下，無論retry多少次，結果都是一樣的糟。可是在Eiffel里情形不同。如果各方面對于契約都做到很好的遵循，那么真正發生異常的時候，我們大可以比較有把握的說，這可能是一個很偶然的事件導致的。比如說網絡環境下，另一個用戶在那一瞬間突然對文件實施了一個操作，或者硬件的一次偶然異常。對于這種情況，“再試一次”成了合情合理的選擇。我們很可能將異常扼殺在搖籃之中，從而不給上層模塊帶來任何影響。
誰說契約思想不偉大呢？