finally丟失的違例

meteorm

無論一個違例是否在try塊中發(fā)生，我們經常都想執(zhí)行一些特定的代碼。對一些特定的操作，經常都會遇到這種情況，但在恢復內存時一般都不需要（因為垃圾收集器會自動照料一切）。為達到這個目的，可在所有違例控制器的末尾使用一個finally從句（注釋④）。所以完整的違例控制小節(jié)象下面這個樣子：
try {
// 要保衛(wèi)的區(qū)域：
// 可能“擲”出A,B,或C的危險情況
} catch (A a1) {
// 控制器 A
} catch (B b1) {
// 控制器 B
} catch (C c1) {
// 控制器 C
} finally {
// 每次都會發(fā)生的情況
缺點：丟失的違例
一般情況下，Java的違例實施方案都顯得十分出色。不幸的是，它依然存在一個缺點。盡管違例指出程序里存在一個危機，而且絕不應忽略，但一個違例仍有可能簡單地“丟失”。在采用finally從句的一種特殊配置下，便有可能發(fā)生這種情況：
//: LostMessage.java
// How an exception can be lost
class VeryImportantException extends Exception {
  public String toString() {
    return "A very important exception!";
  }
}
class HoHumException extends Exception {
  public String toString() {
    return "A trivial exception";
  }
}
public class LostMessage {
  void f() throws VeryImportantException {
    throw new VeryImportantException();
  }
  void dispose() throws HoHumException {
    throw new HoHumException();
  }
  public static void main(String[] args)
      throws Exception {
    LostMessage lm = new LostMessage();
    try {
      lm.f();
    } finally {
      lm.dispose();
    }
  }
} ///:~
輸出如下：
A trivial exception
        at LostMessage.dispose(LostMessage.java:21)
        at LostMessage.main(LostMessage.java:29)
可以看到，這里不存在VeryImportantException（非常重要的違例）的跡象，它只是簡單地被finally從句中的HoHumException代替了。
這是一項相當嚴重的缺陷，因為它意味著一個違例可能完全丟失。而且就象前例演示的那樣，這種丟失顯得非�！白匀弧�，很難被人查出蛛絲馬跡。而與此相反，C++里如果第二個違例在第一個違例得到控制前產生，就會被當作一個嚴重的編程錯誤處理�；蛟SJava以后的版本會糾正這個問題（上述結果是用Java 1.1生成的）。


本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u/19919/showart_2161392.html