例外處理 (2)：名詞解釋

Failures (失敗), faults (缺陷), errors (錯誤), 和 exceptions (例外、異常) 是我們在討論到例外處理時，經常會看到的幾個名詞。這些名詞看起來很像，而且也經常被當成同義字交互使用。然而事實上它們卻有著不同的涵義。瞭解這些名詞的定義將是我們探討例外處理的第一步。

當一個軟體元件 (或是程式) 無法依據其功能性規格 (functional specification) 提供正常的服務時，我們說這個元件的執行結果失敗 (A failure occurs when the service provided by a component departs from its functional specification)。Errors 是元件內部的狀態 (state)，此狀態可能導致該元件執行失敗。Errors 的例子有，null objects, stack overflow。Faults 則是導致錯誤發生的根本原因。

Faults 可以區分為兩大類：design fault 和 component fault。Design faults 又稱為 defects 或 bugs，是人們在軟體開發過程中所犯的問題。例如，忘記初始化物件、把除數設定為零、演算法設計錯誤等。Component faults 則是指軟體元件與軟體元件之間，或是軟體元件與執行環境之間互動時所產生的不正常情況。例如，一個原本運作正常的網路連線忽然中斷、儲存資料時發現硬碟空間不足、列印檔案時印表機未開啟等等。在開發軟體時，除非這兩類的 faults 有被妥善處理，否則 faults 將導致 errors，進一步使得軟體的執行產生 failures (fault->error->failure)。

Exceptions 則是程式語言中用來表達 errors 與 failures 的一種概念。舉例說明，當我們在某個 method X 內部偵測的一個 exception，此時該 exception 表示一個 error；也就是說，method X 處於某種錯誤狀態。如果我們不作任何處理，則該 exception 會傳遞給 method X 的呼叫者。因此，從呼叫者的角度來看，此時該 exception 就代表了一個 failure；也就是說，執行 method X 失敗。

參考資料：

1. A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing,” IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, 2004.
2. A. F. Garcia, C. M. F. Rubira, A. Romanovsky, and J. Xu, “A Comparative Study of Exception Handling Mechanisms for Building Dependable Object-Oriented Software,” Journal of Systems and Software, vol. 59, no. 2, pp.197-222, 2001.
3. P. A. Lee and T. Anderson, Fault Tolerance: Principles and Practice, 2nd ed., Springer, 1990.

例外處理 (1)

兩、三個月前Teddy買了一支具有GPS導航功能的PDA手機。在新鮮感還沒消失之前，Teddy在網路上到處尋找關於PDA手機的資料。其中有人提到，使用這類的PDA手機 (執行 Windows Mobile OS)，過一陣子就要幫它「插屁屁」。因為這些裝置相對於PC比較容易當機 (不知是應用軟體沒寫好，還是作業系統不穩)，所以經常需要 reset。有些機種將 reset 按鈕設計在機體的下方，為了避免使用的人不小心按到 reset 按鈕，所以 reset 按鈕都設計成凹進去的，需要用觸控筆尖尖的那一端來碰觸 reset 按鈕。

用了沒多久之後，Teddy強烈感受到「插屁屁」的必要性。為什麼PDA手機這麼容易當機 ?! 好像時空倒轉，回到當年那 Windows 3.0/3.1 藍底白字的時代，需要不斷的按下 reset 按鈕。

軟體出問體導致電腦當機的原因當然很多，其中有一項常見的現象，就是忽略例外 (ignoring exceptions)。妥善的處理在程式中所發生的例外 (exceptions)，將可增強軟體系統的強固性 (robustness)。簡單的說，就是寫出來的軟體比較不容易「當」。但是，例外處理 (exception handling) 在軟體開發中，一直是個被忽略的一環。對許多程式設計師而言，開發功能需求 (functional requirements) 的時間都不夠了，哪來的閒工夫來設計例外處理。

耶，那麼當程式遇到例外時該怎麼辦 ? 你可能會想，「 嘿嘿，很簡單的啦。只要把例外捉起來 (catch) 然後直接忽略不就好的啦 (有點窩藏犯人的嫌疑)。反正寫程式的是我，我不講老闆也不會知道的啦 。」稍微負責一點的程式設計師可能會把補抓到的例外寫到 log 中，直接列印出來，或是交給程式最外圍 (通常是啟動該程式的函數，例如 main，或是某個 thread ) 的物件來處理。

好把，就算你是一位有理想、有抱負的程式設計師，打算大展身手好好修理一下這些在程式中不請自來的不速之客，但是，要怎麼做 ? 這時候你可能用力回想一下，距今N年前的學生時代，有什麼課有教我們例外處理? 耶，好像沒有。沒關係，身為一位有理想、有抱負的程式設計師，身邊隨時帶著幾本程式語言的書也是很正常的。先翻翻 VB這一本，再看看 C# 這一本，還有C++， Java。奇怪，怎麼好像除了把這個燙手山芋 (例外) 往外丟 (re-throw)，或是直接印到 console 上，就沒什麼特別的處理方法了。 此時，你內心吶喊著：「萬能的天神，請賜予我神奇的力量，讓我好好地處理這些該死的例外吧!」

日後Teddy將撰寫一系列有關例外處理的文章。這個主題是Teddy博士論文研究的一部份，其實裡面也沒什麼偉大的理論，不過是將現今分散在不同學科中，關於例外處理的方法做一些整理。以下列出一些參考文獻，這些資料對於如何處理例外有很實際的建議，有興趣的人可以找來看一下。

參考資料

1. J. Bloch, Effective Java Programming Language Guide, Prentice Hall PTR, 2001.
   
2. J. Shore, “Fail Fast,” IEEE Software, vol. 21, no. 5, 2004, pp. 21-25.
   
3. S. Stelting, Robust Java: Exception Handling, Testing and Debugging, Prentice Hall PTR, 2005.
4. R. Wirfs-Brock, “Designing for Recovery,” IEEE Software, vol. 23, no. 4, July/August 2006, pp.11-13.
5. R. Wirfs-Brock, “Toward Exception-Handling Best Practices and Patterns,” IEEE Software, vol. 23, no. 5, Sep./Oct. 2006, pp.11-13.
   
   

Eclipse 使用技巧－自動產生 Getters 與 Setters

前言

為類別 (class) 的屬性 (attributes or date members ) 加上 getter 與 setter methods， 是一件很簡單但卻有點煩人的工作。善用Eclipse 所提供的自動產生getter 與 setter功能，將可大幅減輕程式設計的負擔並減少錯誤。

Student類別範例

如圖1所示，有一個 Student 類別，其中包含了兩個屬性，分別為 name 與 age。在Eclipse中，可以在該程式的工作區域中，按下滑鼠右鍵，選擇SourceàGenerate Getters and Setters以自動產生Getters 與 Setters（參考圖2）。

圖1：Student 類別

圖2：準備產生 Getters 與 Setters

之後，出現如圖3所示之畫面，在此我們可點選所要產生的Getters 與Setters。

圖3：選擇所要產生的Getters 與 Setters

圖4：Eclipse自動產生的Getters 與 Setters

圖4為Eclipse幫我們自動產生的 Getters 與 Setters。到此都非常簡單。但是，有些程式設計師喜歡在類別屬性之前加上 m_ 作為區別，如此一來，Eclipse 幫我們產生的Getters 與 Setters就會變成圖5的形式。原本的 getName()與getAge()，分別變成了 getM_name() 與 getM_age()；而setName()與setAge()，則變成了setM_name() 與 setM_age()。這顯然不是我們希望的 Getters 與 Setters。

設定Eclipse 以產生正常的Getters 與 Setters

要修正上述問題，我們必須讓Eclipse知道我們對於屬性以 m_ 開頭的命名習慣。

請參考圖6，選擇 WindowàPreferences，之後出現如圖7之畫面。在圖7左方，我們點選 JavaàCode Style，並將右邊畫面的Fields 這個 Variable type 的Prefix list改為 m_。設定好之後我們讓Eclipse再產生一次Getters 與 Setters，此時就可得到正確的Getters 與 Setters（請參考圖8）。

圖5：將屬性加上 m_ 之後，Eclipse所產生的Getters 與 Setters

圖6：選擇WindowàPreferences 以執行Eclipse 設定功能

圖7：將Fields 這個Variable type 的Prefix list改為 m_

圖8：產生正確的 Getters 與 Setters

Pattern Languages and Patterns

樣式語言的起源

樣式語言 (Pattern Language) 一詞，起源於 Christopher Alexander在1970年代前後對於建築領域所做的理論研究與實作 [1,2,3,4]。Alexander認為樣式 (Pattern) 可有效解決在特定建築領域中，一再重複出現的問題。Alexander期待建築樣式語言的存在，不僅對於建築師有意義，而是所有使用者(也就是一般的民眾) 皆可使用該樣式語言來建造一個有活力與生氣蓬勃的家園。樣式與樣式語言彼此相關但卻不可畫上等號，Alexander在[3]中詳細討論了兩者的關係。簡單地說，一個樣式是對於在特定環境與條件下，一再重複發生問題的解；而一個樣式語言，則是一群相關樣式的集合，在其中每個樣式彼此相互強化。

樣式語言不是正規語言，而是比較像自然語言[3]。Alexander在[1,3]中論述樣式語言的理論基礎，[2]為 Alexander 與其團隊依此理論基礎所建立的253個建築樣式。Alexander 對於樣式的實驗，紀錄於[5]中。

軟體社群與樣式語言

Alexander 對於樣式語言的研究，在1990年代初期，啟發了軟體社群對於應用樣式語言的興趣。在各種不同的軟體設計樣式文獻中，最為人們所熟知的，應首推GoF的設計樣式一書 [5]。迄今，軟體設計社群與工業界已經十分成功地應用亞氏的樣式語言觀念，且大量使用於軟體設計、軟體分析、軟體架構、軟體測試與軟體重整等。

從1994年起在北美所舉辦的 PLoP (Pattern Language of Programming) 研討會，已成為樣式社群發表與討論樣式的重要集會。現今，除北美外，相似的研討會亦在世界各地舉辦，其中包括：EuroPLoP、VikingPLoP、SugarLoafPLoP 與 KoalaPLoP 等。這些研討會所接受的論文，並不侷限於軟體設計，而包括了人機互動與教育領域等多樣化的應用。

其他社群對於樣式語言的應用

近年來，人機互動 (human-computer interaction, HCI) 社群也套用樣式來解決人機互動設計與介面可用性的問題。例如，Jennifer Tidwell 建立了超過50個人機介面設計樣式與10個樣式子語言[6]。她的研究廣泛地被認為是目前在人機介面設計中，最有企圖成為人機介面樣式語言的研究。Tidwell同時指出，軟體設計中的樣式，大部分都是從開發者的觀點出發，而不像 Alexander 原始的構想，由終端使用者的角度。這種終端使用者的觀點，並不表示軟體樣式是無用地。相反地，軟體樣式十分成功，而這樣的成功也吸引其他社群套用樣式語言。軟體社群由開發者的觀點來尋找樣式，使得終端使用者無法直接使用軟體樣式來設計軟體，而這正是亞氏對於樣式語言的期待－終端使用者可以直接使用樣式來從事設計。在HCI樣式中，大部分採用了終端使用者的觀點，而使得HCI樣式語言更接近亞氏的樣式語言。

此外，學習社群也使用樣式的觀念於教學法、教學設計與學習科技系統設計上。一個公開的教學法樣式網站已被建立，用以共享其樣式 [7]。

深入了解樣式與樣式語言

要了解樣式與樣式語言，最好的方式是閱讀 [2, 3] 這兩本書。另一個選擇則是閱讀最近出版的 Pattern-Oriented Software Architecture 5 (POSA 5) [8]。 這本書的內容就在探討 Pattern 與 Pattern Language 的關係。和 Alexander 的書所不同，POSA 5 主要以軟體的角度來探討兩者之間的關係。

參考資料:

1. C. Alexander, Notes on the Synthesis of Form, Oxford University Press, 1970.
2. C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel, A Pattern Language, Oxford University Press, 1977.
3. C. Alexander, The Timeless Way of Building, Oxford University Press, 1979.
4. C. Alexander, M. Siverstein, S. Angel, S. Ishikawa, and D. Abrams, The Oregon Experiment, Oxford University Press, 1988.
5. E. Gamma, R. Helms, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
6. J. Tidwell, "Common Ground", http://www.mit.edu/~jtidwell/, 1999.
7. Pedagogical Patterns, http://www.pedagogicalpatterns.org/.
   
8. F. Buschmann, K. Henney, and D. C. Schmidt, Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages, Wiley, 2007.