例外處理的四種Context（3）：Application Context

Nov. 06 10:26~11:40

 

有時候光是依靠exception context、object context、local context，還是無法決定例外處理的設計方法，這時候就需要參考application context。Application context從整個應用程式，也就是從軟體架構的角度，來評估例外處理的策略。

***

Teddy ：請問收到一個IOException要如何處理？

鄉民甲：不知道，這種沒頭沒尾的問題要怎麼回答？

 

 

沒頭沒尾的問題的確無法回答，請看上圖，這是一個超級簡化過的網路遊戲軟體架構圖，其中有三個主要的元件：

• Acceptor：程式啟動之後Acceptor會監聽某一個TCP port，負責接受來自於網路的連線。
• GameServer：負責遊戲的邏輯。
• AppWin：負責顯示遊戲畫面。

假設當Acceptor要監聽某個port但卻發現這個port已經被其他人給使用了，因此接收到一個IOException，請問Acceptor該如何處理這個例外？

從exception context，可以知道這個IOException代表某個TCP port被使用，再從local context與object context，可以知道Acceptor所負擔的責任就是要去監聽某一個TCP port。

***

鄉民甲：我知道了，如果原本的port被別人使用，那Acceptor就使用其他的port就好了，這樣上層的GameServer就不會被這個例外所影響，程式還是可以正常運作。

Teddy ：讓Acceptor自行嘗試其他的port的確是一種方法，但是如果原先的port是對外公開的號碼，如果隨便自行修改別人可能會無法和你溝通那怎麼辦？又或者，原本的port被占用可能代表還有另外一個相同應用程式還在執行當中，如果Acceptor自行挑選其他的port然後假裝沒有任何例外發生，那麼使用者開始玩遊戲之後可能會遭遇到一些奇怪的現象，例如有些封包被另外一個還在執行的應用程式給收走。

鄉民甲：那，你的意思是說Acceptor不管遇到什麼例外都一律往上丟？

Teddy ：也不是這個意思，從application context（軟體架構）的角度來看，Acceptor位於應用程式的底層。通常越底層的元件，被重複使用的機會相對越高。如果這樣的元件當初設計的時候就針對某一個特定的context做了例外處理的最佳化，則該元件在其他context裡面被使用的機會就會減低。

Teddy ：再者，越底層的元件通常沒有足夠的application context，不知道自己將來會被用在那些應用情境之中。因此，通常也沒有足夠的知識來做好例外處理的設計。

鄉民甲：所以說，如果底層所擁有的application context不足夠，那麼就應該把例外狀況向外回報，讓上層的人有機會可以處理？

Teddy ：基本上的精神是這樣的。就好像基層員工遇到例外狀況無法應付，就應該向上層主管回報，讓擁有更高權限的主管來處理。

鄉民甲：那在這個例子裏面，這個IOException應該交給GameServer還是AppWin來處理？

Teddy ：這還是要看軟體架構設計與各層責任分工來決定，以這個例子來看，GameServer應該是擁有足夠的資訊可以來做處理。例如GameServer可以嘗試先檢查是否已經有一個相同應用程式正在執行，如果有則嘗試終止它，或是顯示警告訊息給使用者。又或者，GameServer可以改變系統配置，然後重新呼叫Acceptor透過其他port來接受網路連線。

***

俗話說：「能力越大，責任愈大」，擁有越多資訊的人，理應處理更棘手的例外。

***

友藏內心獨白：還有沒有其他類型的context？