缺点：丢失的违例

一般环境下，Java的违例实施方案都显得十分精彩。不幸的是，它依然存在一个缺点。尽量违例指出措施里存在一个危机，并且毫不该忽略，但一个违例仍有大概简朴地“丢失”。在回收finally从句的一种非凡设置下，便有大概产生这种环境：
 

//: 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++里假如第二个违例在第一个违例获得节制前发生，就会被看成一个严重的编程错误处理惩罚。或者Java今后的版本会更正这个问题（上述功效是用Java 1.1生成的）。