淺談.net和Java的異常類型設計

最近在自學Java，看到Java的檢查型異常設計時，心中不免有些疑惑。疑惑使用檢查型異常的必要性。註：本人現在從事的.net開發。C#在設計上借鑒了Java，但是，C# 並沒有引入所謂的檢查型異常。

 

在網上看到一些關於Java中是否該採用檢查型異常的機制。真是眾說紛紜，但是還是可以總結為，對這個設計的批評聲更多。其實，我沒有在真正項目中使用Java開發的經驗，更沒有過在方法簽名中聲明檢查型異常的經驗。但是，在使用了C#這個長時間以來，也沒有覺得C#完全拋棄檢查型異常帶來怎樣的不便和設計上的缺陷。

 

據說，C#的設計人員大都有很長時間的Java語言開發經驗（怪不得從文法到機制上都是這麼驚人的相似），也怪不得他們不引入檢查型異常，估計是深受其苦吧。

 

我的感覺是，在.net的任何語言中引入檢查型異常真的是弊大於利。物件導向中大家都知道一個原則——開放封閉原則。我們在設計的時候總是儘可能地考慮到擴充性，儘可能避免對已有實現的修改。當然，完全不修改幾乎沒有可能。但是我們傾向於“配置”。將一些改變更配置置在設定檔中，將耦合性降到最低。這樣的好處有很多：可以用採用反射機制根據設定檔動態載入等。採用檢查型異常的機制很明顯，使配置的種種優點無法發揮作用。

 

一旦採用這種機制，方法的簽名就將與各種異常類型產生緊密的耦合關係。一旦設計或者異常使用不當，需要進行改動，然後重新編譯。特別是存在多層調用關係的時候，這樣的修改關係就更為複雜。並且，也很難發揮物件導向的一些優勢，比如多態。但是，有時確實需要提醒方法的調用者，某個方法確實存在很大的產生某種異常的風險（比如I/O、或者資料庫異常），需要加以處理。這在C#中也做到了——是在調用類庫方法的時候，智能提示產生的方法注釋中告訴了客戶程式，該方法將會產生哪些異常，需要注意捕獲。說明C#中還是注意到了這一點。當然，如果你作為一個類庫開發人員或者開發人員，也可以這麼做。

 

同時採用檢查型異常，也很好地暴露了不必要的資訊，有些意圖從異常類中就可以加以揣測。這從某種程度上失去了資訊的隱蔽性，但是，這個帶來的好處應該遠大於它的負面作用。採用檢查型異常，可以很清楚地指示方法本身和主調方法遵循相應的規則。這個會使開發更加正常化。我想，這也是Java語言設計團隊認為幾乎一定要採用這種方式的原因吧。但是，我還是沒有想到一個一定要使用的理由。

 

.net中的完全拋棄檢查型異常，也會使得異常處理變得不那麼實用和高效。因為，如果沒有很好的文檔作指導或者注釋不規範，很容易你就丟失了對異常資訊的掌握。但是，個人還是不覺得.net中引入檢查型異常帶來的好處更多，其實，如果在開發時文檔正常化一些，就能夠彌補缺失檢查型異常的不足，但是，你知道的這是不可能的。

 

我覺得Java中也沒有說應該完全拋棄檢查型異常。存在的就是合理的。只要是適度使用。由於本人暫未有任何Java的項目經驗，所以暫時不敢說有什麼心得，期待在使用中能有點感悟。