例外處理的四種Context（2）：Object Context與Local Context

Nov. 05 21:09~22:45

 

今天介紹object context與local context這兩種context，其實這兩種context和例外處理沒有特別的關係，平常寫程式的時候也存在著這樣的概念。因為「例外處理設計」最後要被程式給實做出來，所以一併把這兩種context介紹一下。

Object Context

在物件導向的程式語言之中，object context表示在一個object裡面可以存取到的資訊，包含了object的data member以及全域變數。

在《例外處理的四種Context（1）：Exception Context》裡面提到，例外處理程式可以透過exception context來獲得一些例外處理的資訊。同樣地，也可以從object context獲得例外處理的資訊。請參考下列程式片段，ObjectContext物件有六個data member，這些資料都有可能在例外處理程式中被使用。另外，第33~35的例外處理程式，可以把SQLException發生的時候，使用者所使用的資料庫種類、帳號、資料庫名稱、資料庫連線的port number等資料寫到日誌檔裡面。

***

Local Context

廣義的來講，任何的程式區塊所形成的一個範圍（scope）便可以算是一個local context。在這邊以一個method當作一個local context的範圍（因為很多程式語言的例外處理者都是位於method裡面）。

以下列程式片段為例，fetchRawBytesAndSetupMessage() method所傳入的參數、method裡面的區域變數、以及實作程式碼就形成了例外處理所關心的local context。

 

再看下面另外一個例子，為什麼dumpFileContent()和fetchRawBytesAndSetupMessage()都遇到EOFException，但是兩者的處理方式卻不同？如果光是從exception context，鄉民們只知道捕捉到EOFException這種型態的例外，以及該例外的stack trace等資料，對於判斷這個例外要如何處理沒什麼幫助。因此再往外尋找，看看在local context或是object context裡面，能不能找到如何處理例外的蛛絲馬跡。

從dumpFileContent()和fetchRawBytesAndSetupMessage()的實作程式碼，可以發現在dumpFileContent()中，EOFException被作為一種「狀態通知」的用途，表示已經讀到檔案的結尾。因為dumpFileContent()用來印出檔案的內容，因此讀到檔案的結尾之後丟出EOFException實屬正常現象，請安心服用，不須特別處理。

但是fetchRawBytesAndSetupMessage()就不一樣，第105行aIS.readFully(messageBody)預期從aIS物件讀取一定長度的資料，如果此時發生EOFException，則表示資料來源不完整，因此在第107行丟出一個InvalidPacketException("Data Underflow")來表示資料不完整這個例外情況。

以上兩個不同的local context例子，也引導出兩種不同的例外處理設計方法。

***

例外處理和打仗很類似，打仗需要知道戰場的地形、地物、天候、敵人裝備與部署等資料（作戰的context），而例外處理也必須借用exception context、object context、local context，以及下一集要介紹的application context等資訊來設計合適的例外處理程式。

***

友藏內心獨白：有點像是俄羅斯娃娃的感覺。