# 9.5 異常的限制
覆蓋一個方法時,只能產生已在方法的基類版本中定義的異常。這是一個重要的限制,因為它意味著與基類協同工作的代碼也會自動應用于從基類派生的任何對象(當然,這屬于基本的OOP概念),其中包括異常。
下面這個例子演示了強加在異常身上的限制類型(在編譯期):
```
//: StormyInning.java
// Overridden methods may throw only the
// exceptions specified in their base-class
// versions, or exceptions derived from the
// base-class exceptions.
class BaseballException extends Exception {}
class Foul extends BaseballException {}
class Strike extends BaseballException {}
abstract class Inning {
Inning() throws BaseballException {}
void event () throws BaseballException {
// Doesn't actually have to throw anything
}
abstract void atBat() throws Strike, Foul;
void walk() {} // Throws nothing
}
class StormException extends Exception {}
class RainedOut extends StormException {}
class PopFoul extends Foul {}
interface Storm {
void event() throws RainedOut;
void rainHard() throws RainedOut;
}
public class StormyInning extends Inning
implements Storm {
// OK to add new exceptions for constructors,
// but you must deal with the base constructor
// exceptions:
StormyInning() throws RainedOut,
BaseballException {}
StormyInning(String s) throws Foul,
BaseballException {}
// Regular methods must conform to base class:
//! void walk() throws PopFoul {} //Compile error
// Interface CANNOT add exceptions to existing
// methods from the base class:
//! public void event() throws RainedOut {}
// If the method doesn't already exist in the
// base class, the exception is OK:
public void rainHard() throws RainedOut {}
// You can choose to not throw any exceptions,
// even if base version does:
public void event() {}
// Overridden methods can throw
// inherited exceptions:
void atBat() throws PopFoul {}
public static void main(String[] args) {
try {
StormyInning si = new StormyInning();
si.atBat();
} catch(PopFoul e) {
} catch(RainedOut e) {
} catch(BaseballException e) {}
// Strike not thrown in derived version.
try {
// What happens if you upcast?
Inning i = new StormyInning();
i.atBat();
// You must catch the exceptions from the
// base-class version of the method:
} catch(Strike e) {
} catch(Foul e) {
} catch(RainedOut e) {
} catch(BaseballException e) {}
}
} ///:~
```
在`Inning`中,可以看到無論構造器還是`event()`方法都指出自己會“拋”出一個異常,但它們實際上沒有那樣做。這是合法的,因為它允許我們強迫用戶捕獲可能在覆蓋過的event()版本里添加的任何異常。同樣的道理也適用于`abstract`方法,就象在`atBat()`里展示的那樣。
`interface Storm`非常有趣,因為它包含了在`Incoming`中定義的一個方法——`event()`,以及不是在其中定義的一個方法。這兩個方法都會“拋”出一個新的異常類型:`RainedOut`。當執行到`StormyInning extends`和`implements Storm`的時候,可以看到`Storm`中的`event()`方法不能改變`Inning`中的`event()`的異常接口。同樣地,這種設計是十分合理的;否則的話,當我們操作基類時,便根本無法知道自己捕獲的是否正確的東西。當然,假如`interface`中定義的一個方法不在基類里,比如`rainHard()`,它產生異常時就沒什么問題。
對異常的限制并不適用于構造器。在`StormyInning`中,我們可看到一個構造器能夠“拋”出它希望的任何東西,無論基類構造器“拋”出什么。然而,由于必須堅持按某種方式調用基類構造器(在這里,會自動調用默認構造器),所以派生類構造器必須在自己的異常規范中聲明所有基類構造器異常。
`StormyInning.walk()`不會編譯的原因是它“拋”出了一個異常,而`Inning.walk()`卻不會“拋”出。若允許這種情況發生,就可讓自己的代碼調用`Inning.walk()`,而且它不必控制任何異常。但在以后替換從`Inning`派生的一個類的對象時,異常就會“拋”出,造成代碼執行的中斷。通過強迫派生類方法遵守基類方法的異常規范,對象的替換可保持連貫性。
覆蓋過的`event()`方法向我們顯示出一個方法的派生類版本可以不產生任何異常——即便基類版本要產生異常。同樣地,這樣做是必要的,因為它不會中斷那些已假定基類版本會產生異常的代碼。差不多的道理亦適用于`atBat()`,它會“拋”出`PopFoul`——從`Foul`派生出來的一個異常,而`Foul`異常是由`atBat()`的基類版本產生的。這樣一來,假如有人在自己的代碼里操作`Inning`,同時調用了`atBat()`,就必須捕獲`Foul`異常。由于`PopFoul`是從`Foul`派生的,所以異常控制器(模塊)也會捕獲`PopFoul`。
最后一個有趣的地方在`main()`內部。在這個地方,假如我們明確操作一個`StormyInning`對象,編譯器就會強迫我們只捕獲特定于那個類的異常。但假如我們向上轉換到基類型,編譯器就會強迫我們捕獲針對基類的異常。通過所有這些限制,異常控制代碼的“健壯”程度獲得了大幅度改善(注釋③)。
③:ANSI/ISO C++施加了類似的限制,要求派生方法異常與基類方法拋出的異常相同,或者從后者派生。在這種情況下,C++實際上能夠在編譯期間檢查異常規范。
我們必須認識到這一點:盡管異常規范是由編譯器在繼承期間強行遵守的,但異常規范并不屬于方法類型的一部分,后者僅包括了方法名以及參數類型。因此,我們不可在異常規范的基礎上覆蓋方法。除此以外,盡管異常規范存在于一個方法的基類版本中,但并不表示它必須在方法的派生類版本中存在。這與方法的“繼承”頗有不同(進行繼承時,基類中的方法也必須在派生類中存在)。換言之,用于一個特定方法的“異常規范接口”可能在繼承和覆蓋時變得更“窄”,但它不會變得更“寬”——這與繼承時的類接口規則是正好相反的。
- Java 編程思想
- 寫在前面的話
- 引言
- 第1章 對象入門
- 1.1 抽象的進步
- 1.2 對象的接口
- 1.3 實現方案的隱藏
- 1.4 方案的重復使用
- 1.5 繼承:重新使用接口
- 1.6 多態對象的互換使用
- 1.7 對象的創建和存在時間
- 1.8 異常控制:解決錯誤
- 1.9 多線程
- 1.10 永久性
- 1.11 Java和因特網
- 1.12 分析和設計
- 1.13 Java還是C++
- 第2章 一切都是對象
- 2.1 用引用操縱對象
- 2.2 所有對象都必須創建
- 2.3 絕對不要清除對象
- 2.4 新建數據類型:類
- 2.5 方法、參數和返回值
- 2.6 構建Java程序
- 2.7 我們的第一個Java程序
- 2.8 注釋和嵌入文檔
- 2.9 編碼樣式
- 2.10 總結
- 2.11 練習
- 第3章 控制程序流程
- 3.1 使用Java運算符
- 3.2 執行控制
- 3.3 總結
- 3.4 練習
- 第4章 初始化和清除
- 4.1 用構造器自動初始化
- 4.2 方法重載
- 4.3 清除:收尾和垃圾收集
- 4.4 成員初始化
- 4.5 數組初始化
- 4.6 總結
- 4.7 練習
- 第5章 隱藏實現過程
- 5.1 包:庫單元
- 5.2 Java訪問指示符
- 5.3 接口與實現
- 5.4 類訪問
- 5.5 總結
- 5.6 練習
- 第6章 類復用
- 6.1 組合的語法
- 6.2 繼承的語法
- 6.3 組合與繼承的結合
- 6.4 到底選擇組合還是繼承
- 6.5 protected
- 6.6 累積開發
- 6.7 向上轉換
- 6.8 final關鍵字
- 6.9 初始化和類裝載
- 6.10 總結
- 6.11 練習
- 第7章 多態性
- 7.1 向上轉換
- 7.2 深入理解
- 7.3 覆蓋與重載
- 7.4 抽象類和方法
- 7.5 接口
- 7.6 內部類
- 7.7 構造器和多態性
- 7.8 通過繼承進行設計
- 7.9 總結
- 7.10 練習
- 第8章 對象的容納
- 8.1 數組
- 8.2 集合
- 8.3 枚舉器(迭代器)
- 8.4 集合的類型
- 8.5 排序
- 8.6 通用集合庫
- 8.7 新集合
- 8.8 總結
- 8.9 練習
- 第9章 異常差錯控制
- 9.1 基本異常
- 9.2 異常的捕獲
- 9.3 標準Java異常
- 9.4 創建自己的異常
- 9.5 異常的限制
- 9.6 用finally清除
- 9.7 構造器
- 9.8 異常匹配
- 9.9 總結
- 9.10 練習
- 第10章 Java IO系統
- 10.1 輸入和輸出
- 10.2 增添屬性和有用的接口
- 10.3 本身的缺陷:RandomAccessFile
- 10.4 File類
- 10.5 IO流的典型應用
- 10.6 StreamTokenizer
- 10.7 Java 1.1的IO流
- 10.8 壓縮
- 10.9 對象序列化
- 10.10 總結
- 10.11 練習
- 第11章 運行期類型識別
- 11.1 對RTTI的需要
- 11.2 RTTI語法
- 11.3 反射:運行期類信息
- 11.4 總結
- 11.5 練習
- 第12章 傳遞和返回對象
- 12.1 傳遞引用
- 12.2 制作本地副本
- 12.3 克隆的控制
- 12.4 只讀類
- 12.5 總結
- 12.6 練習
- 第13章 創建窗口和程序片
- 13.1 為何要用AWT?
- 13.2 基本程序片
- 13.3 制作按鈕
- 13.4 捕獲事件
- 13.5 文本字段
- 13.6 文本區域
- 13.7 標簽
- 13.8 復選框
- 13.9 單選鈕
- 13.10 下拉列表
- 13.11 列表框
- 13.12 布局的控制
- 13.13 action的替代品
- 13.14 程序片的局限
- 13.15 視窗化應用
- 13.16 新型AWT
- 13.17 Java 1.1用戶接口API
- 13.18 可視編程和Beans
- 13.19 Swing入門
- 13.20 總結
- 13.21 練習
- 第14章 多線程
- 14.1 反應靈敏的用戶界面
- 14.2 共享有限的資源
- 14.3 堵塞
- 14.4 優先級
- 14.5 回顧runnable
- 14.6 總結
- 14.7 練習
- 第15章 網絡編程
- 15.1 機器的標識
- 15.2 套接字
- 15.3 服務多個客戶
- 15.4 數據報
- 15.5 一個Web應用
- 15.6 Java與CGI的溝通
- 15.7 用JDBC連接數據庫
- 15.8 遠程方法
- 15.9 總結
- 15.10 練習
- 第16章 設計模式
- 16.1 模式的概念
- 16.2 觀察器模式
- 16.3 模擬垃圾回收站
- 16.4 改進設計
- 16.5 抽象的應用
- 16.6 多重分發
- 16.7 訪問器模式
- 16.8 RTTI真的有害嗎
- 16.9 總結
- 16.10 練習
- 第17章 項目
- 17.1 文字處理
- 17.2 方法查找工具
- 17.3 復雜性理論
- 17.4 總結
- 17.5 練習
- 附錄A 使用非JAVA代碼
- 附錄B 對比C++和Java
- 附錄C Java編程規則
- 附錄D 性能
- 附錄E 關于垃圾收集的一些話
- 附錄F 推薦讀物