Detaillierte Einführung und Analyse des Java-Ausnahmemodells (Bild)

1. Einführung und Grundlagen von Ausnahmen

Der ideale Zeitpunkt, um Fehler zu finden, ist während der Kompilierungsphase, also bevor Sie versuchen, das Programm auszuführen. Allerdings kann der Compiler beim Kompilieren nicht alle Fehler finden und beheben. Diese Art von Fehler ist . Dies erfordert, dass die Fehlerquelle auf irgendeine Weise entsprechende Informationen an einen Empfänger weitergibt, und der Empfänger weiß, wie er das Problem richtig behandeln kann. Dies ist Javas FehlerberichtMechanismus – Abnormaler Mechanismus . Dieser Mechanismus ermöglicht es dem Programm, Code für das, was während der normalen Ausführung zu tun ist, vom Code für das, was zu tun ist, wenn etwas schief geht, zu trennen.
　
　 In Bezug auf die Ausnahmebehandlung verwendet Java das Beendigungsmodell. In diesem Modell wird davon ausgegangen, dass der Fehler so kritisch ist, dass das Programm nicht zu dem Punkt zurückkehren kann, an dem die Ausnahme aufgetreten ist, um die Ausführung fortzusetzen. Sobald eine Ausnahme ausgelöst wird, bedeutet dies, dass der Fehler irreversibel ist und die Ausführung nicht fortgesetzt werden kann. Im Vergleich zum Beendigungsmodell ist das Wiederherstellungsmodell ein weiteres Ausnahmebehandlungsmodell , das es dem Programm ermöglicht, die Ausführung fortzusetzen, nachdem die Ausnahme behandelt wurde. Obwohl dieses Modell attraktiv ist, ist es nicht sehr praktisch, vor allem aufgrund der Kopplung, zu der es führt: Der Wiederherstellungshandler muss wissen, wo die Ausnahme ausgelöst wurde, die zwangsläufig nicht generischen Code enthält, der vom Auslöseort abhängt, und somit erheblich zunimmt die Schwierigkeit beim Schreiben und Warten von Code.
　
In einer Ausnahmesituation wird das Auslösen einer Ausnahme von den folgenden drei Dingen begleitet:

• Zuallererst das Gleiche wie bei anderen Objekten in Java Wie bei der Erstellung wird das Ausnahmeobjekt mit newSeconds erstellt ,

Der aktuelle Ausführungspfad wird beendet

• und der Verweis auf das Ausnahmeobjekt wird aus der aktuellen Umgebung entfernt; 🎜>Schließlich Der Ausnahmebehandlungsmechanismus übernimmt das Programm und beginnt mit der Suche nach dem entsprechenden Ausnahmehandler und stellt das Programm aus dem Fehlerstatus

  wieder her
.

• 2. Java-Standardausnahmen1.Grundlegende Konzepte

　　　

---

　　　　　

Beispiel für eine Ausnahmeklassenhierarchie

　　　　　　　　　　　　　　 -

Throwable: Die Stammklasse aller Ausnahmetypen

In Java ist Throwable die Stammklasse aller Ausnahmetypen.

Throwable hat zwei direkte Unterklassen:

Exception

und Error. Beide sind wichtige Unterklassen der Java-Ausnahmebehandlung und jede enthält eine große Anzahl von Unterklassen. - Fehler: Ein Fehler, der vom Programm selbst nicht behandelt werden kann 　Fehler ist ein Fehler, der vom Programm nicht behandelt werden kann und auf ein schwerwiegendes Problem bei der Ausführung hinweist Anwendung.

Die meisten dieser Fehler haben nichts mit den vom Codeschreiber ausgeführten Vorgängen zu tun, sondern beziehen sich auf die JVM, Ressourcen usw., wenn der Code ausgeführt wird. Beispielsweise tritt bei Java Virtual Machine Runtime Error (Virtual MachineError) ein OutOfMemoryError auf, wenn die JVM nicht mehr über die erforderlichen Speicherressourcen verfügt, um die Ausführung des Vorgangs fortzusetzen. Wenn diese Ausnahmen auftreten, entscheidet sich die Java Virtual Machine (JVM) im Allgemeinen dafür, den Thread zu beenden.

Diese Fehler können nicht überprüft werden und liegen außerhalb der Kontroll- und Verarbeitungsmöglichkeiten der Anwendung. In Java werden Fehler durch Unterklassen von Error beschrieben. Ausnahme: Fehler, den das Programm selbst verarbeiten kann

Eine Ausnahme ist normalerweise für Java-Programmierer von Belang. Sie kann in der Java-Klassenbibliothek, in Benutzermethoden und bei Laufzeitfehlern auftreten. Es besteht aus zwei Zweigen: Laufzeitausnahmen (Ausnahmen abgeleitet von RuntimeException) und andere Ausnahmen . Die Regeln für die Unterteilung dieser beiden Arten von Ausnahmen sind: verursacht durch Programmfehler (normalerweise logische Fehler, wie z. B. falsche Typkonvertierung, Array außerhalb der Grenzen usw.). ., was vermieden werden sollte) Die Ausnahme gehört zu RuntimeException; es liegt zwar kein Problem mit dem Programm selbst vor, aber die Ausnahme, die durch Fehler wie E/A verursacht wird (z. B. Versuch, eine nicht vorhandene Datei zu öffnen), gehört zu anderen Ausnahmen.

---

Darüber hinaus können Java-Ausnahmen (einschließlich Ausnahme und Fehler) normalerweise in geprüfte Ausnahmen (geprüfte Ausnahmen) unterteilt werden Es gibt zwei Typen: und ungeprüfte Ausnahmen .

• Ungeprüfte Ausnahmen: Alle von Error oder RuntimeException abgeleiteten Ausnahmen

  　Ungeprüfte Ausnahmen werden vom Compiler nicht erkannt. Ausnahmen, die erfordern eine obligatorische Behandlung umfassen Laufzeitausnahmen (RuntimeException und ihre Unterklassen) und Fehler (Error). Mit anderen Worten: Wenn diese Art von Ausnahme im Programm auftritt, wird der Compiler erfolgreich sein, auch wenn sie nicht mit einer Try-Catch-Anweisung abgefangen oder mit einer Throws-Klausel zum Auslösen deklariert wird.

• Überprüfte Ausnahmen: Alle Ausnahmen außer ungeprüften Ausnahmen

  　Überprüfte Ausnahmen werden vom Compiler benötigt. Behandelte Ausnahme. Hier gibt es zwei Verarbeitungsmethoden: Abfangen und Behandeln von Ausnahmen und Deklarieren Auslösen von Ausnahmen . Das heißt, wenn eine solche Ausnahme im Programm auftreten kann, verwenden Sie entweder eine Try-Catch-Anweisung, um sie abzufangen, oder verwenden Sie eine Throws-Klausel, um sie als auszulösen zu deklarieren, andernfalls wird die Kompilierung nicht erfolgreich sein.

• Richtlinie: Wenn eine RuntimeException im Programm auftritt, muss es das Problem des Programmierers sein

• Der Unterschied zwischen Ausnahmen und Fehlern: Ausnahmen können vom Programm selbst behandelt werden, Fehler können jedoch nicht behandelt werden

---

3. Java-Ausnahmebehandlungsmechanismus

1. Ausnahmebehandlung

   In Java-Anwendungen lautet der Ausnahmebehandlungsmechanismus: Ausnahme auslösen und Ausnahmen abfangen.
   　
   　Wirft eine Ausnahme aus: Wenn in einer Methode ein Fehler auftritt und eine Ausnahme ausgelöst wird, erstellt die Methode ein Ausnahmeobjekt und übermittelt es an das Laufzeitsystem. Das Ausnahmeobjekt enthält den Ausnahmetyp und der Programmstatus, wenn die Ausnahme auftritt usw. Ausnahmeinformationen. Das Laufzeitsystem ist dafür verantwortlich, den Code zur Behandlung der Ausnahme zu finden und auszuführen.

   　Abfangen von Ausnahmen: Nachdem die Methode eine Ausnahme ausgelöst hat, sucht das Laufzeitsystem nach einem geeigneten Ausnahmehandler (Ausnahmehandler). Ein potenzieller Ausnahmebehandler ist eine Sammlung von Methoden, die nacheinander im Aufrufstapel verbleiben, wenn eine Ausnahme auftritt. Wenn der Ausnahmetyp, den der Ausnahmehandler verarbeiten kann, mit dem von der Methode ausgelösten Ausnahmetyp übereinstimmt, handelt es sich um einen geeigneten Ausnahmehandler. Das Laufzeitsystem startet bei der Methode, bei der die Ausnahme aufgetreten ist, und überprüft die Methoden im Aufrufstapel, bis es die Methode mit dem entsprechenden Ausnahmehandler findet und diese ausführt. Wenn das Laufzeitsystem den Aufrufstapel durchläuft, ohne einen geeigneten Ausnahmehandler zu finden, wird das Laufzeitsystem beendet. Gleichzeitig bedeutet es die Beendigung des Java-Programms.

Für Laufzeitausnahmen, Fehler oder geprüfte Ausnahmen sind die für die Java-Technologie erforderlichen Ausnahmebehandlungsmethoden unterschiedlich:

---

Da

• Laufzeitausnahmen deaktiviert sind, legt Java Folgendes fest: Laufzeitausnahmen werden automatisch vom Java-Laufzeitsystem ausgelöst, sodass Anwendungen die Laufzeitausnahme ignorieren können

Bei Fehler

• , die während der Ausführung der -Methode auftreten können und die laufende Methode ihn nicht abfangen möchte, lässt Java zu, dass die Methode keine Throw-Anweisung ausführt . Denn die meisten Fehler sind nicht behebbar und Ausnahmen, die vernünftige Anwendungen nicht abfangen sollten.

Für

• alle geprüften Ausnahmen schreibt Java vor, dass Ausnahmen zulässig sind gefangen oder erklärt werden. Das heißt, wenn eine Methode beschließt, keine überprüfbaren Ausnahmen abzufangen, muss sie deklarieren, dass sie eine Ausnahme auslöst

  Jeder Java-Code kann Ausnahmen auslösen, z. B. von Ihnen selbst geschriebener Code, Code aus dem Java-Entwicklungsumgebungspaket oder dem Java-Laufzeitsystem. Jeder kann über die throw-Anweisung von Java eine Ausnahme auslösen.

  　Im Allgemeinen schreibt Java vor, dass überprüfbare Ausnahmen abgefangen oder zum Auslösen deklariert werden müssen. Ermöglicht das Ignorieren nicht überprüfbarer RuntimeException und Fehler.

---

2. Ausnahmebeschreibung

Für geprüfte Ausnahmen stellt Java entsprechende bereit Syntax, die es Ihnen ermöglicht, dem Client-Programmierer die Art der Ausnahme mitzuteilen, die eine bestimmte Methode möglicherweise auslöst, und der Client-Programmierer sie dann entsprechend behandeln kann. Dies ist die Ausnahmebeschreibung , die Teil der Methodendeklaration ist, unmittelbar nach der formalen Parameterliste, wie im folgenden Code dargestellt:

void f() throws TooBig, TooSmall, pZero { ... }

darstellt Die Methode f kann drei Ausnahmen auslösen: TooBig, TooSmall und pZero, während

void g() { ... ... }

bedeutet, dass Methode g keine Ausnahme auslöst.

　Der Code muss mit der Ausnahmebeschreibung übereinstimmen. Wenn der Code in der Methode eine geprüfte Ausnahme generiert, diese aber nicht behandelt, erkennt der Compiler dieses Problem und erinnert Sie daran: Behandeln Sie entweder die Ausnahme oder geben Sie in der Ausnahmebeschreibung an, dass diese Methode eine Ausnahme generiert . Wir können jedoch deklarieren, dass eine Methode eine Ausnahme auslöst, ohne sie tatsächlich auszulösen.

---

3. Ausnahmen abfangen

Überwachungsbereich: Es handelt sich um einen Code, der Ausnahmen generieren kann, gefolgt von Code zur Behandlung dieser Ausnahmen Ausnahmen, wie in try…catch…-Klausel gezeigt, ist implementiert.

　(1) try-Klausel
　Wenn eine Ausnahme innerhalb der Methode ausgelöst wird, beendet diese Methode den Prozess des Auslösens der Ausnahme. Wenn Sie nicht möchten, dass die Methode hier endet, können Sie einen speziellen Block innerhalb der Methode festlegen, um die Ausnahme abzufangen. Unter anderem wird in diesem Block der Teil, der versucht, verschiedene Methoden aufzurufen, als Try-Block bezeichnet:

try { 
    // Code that might generate exceptions }

---

　 (2) Catch-Klausel – Ausnahmehandler
Die ausgelöste Ausnahme muss abgefangen werden Behandlung und für jede abzufangende Ausnahme muss ein entsprechender Ausnahmehandler vorbereitet werden. Der Ausnahmehandler muss dem Try-Block folgen, der durch das Schlüsselwort „catch“ dargestellt wird:

try { 
  // Code that might generate exceptions } catch(Type1 id1)|{ 
  // Handle exceptions of Type1 } catch(Type2 id2) { 
  // Handle exceptions of Type2 } catch(Type3 id3) { 
  // Handle exceptions of Type3 }

Der Ausnahmehandler darf den Bezeichner (id1, id2,. ..), da der Ausnahmetyp selbst genügend Informationen zur Behandlung der Ausnahme bereitgestellt hat, der Bezeichner jedoch nicht weggelassen werden kann. Wenn eine Ausnahme ausgelöst wird, ist der Ausnahmebehandlungsmechanismus dafür verantwortlich, nach dem ersten Handler zu suchen, dessen Parameter mit dem Ausnahmetyp übereinstimmen. Geben Sie dann den entsprechenden Catch ein und führen Sie ihn automatisch aus. Zu diesem Zeitpunkt gilt die Ausnahme als behandelt. Sobald die Catch-Klausel endet, endet die Suche des Handlers (im Gegensatz zu switch…case…).
　
Besonderes Augenmerk sollte auf Folgendes gelegt werden:

• Ausnahmeabgleichsprinzip: Wenn eine Ausnahme ausgelöst wird, Ausnahmebehandlung Das System findet den am besten passenden Handler (ein Objekt der abgeleiteten Klasse kann mit dem Handler seiner Basisklasse übereinstimmen) in der Reihenfolge, in der der Code geschrieben wird. Sobald es gefunden wurde, geht es davon aus, dass die Ausnahme behandelt wird, und hört auf zu suchen Die Klausel muss nach der Catch-Klausel platziert werden, die Ausnahmen ihrer abgeleiteten Klasse erfasst, andernfalls wird die Kompilierung nicht erfolgreich sein.

• Die Catch-Klausel muss mit der Try-Klausel verwendet werden .

• 　(3) finally-Klausel

Die „finally“-Blockbeschreibung

---

　　The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. But finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return,continue, or break. Putting cleanup code in a finally block is always a good practice, even when no exceptions are anticipated.
　　
　　Note: If the JVM exits while the try or catch code is being executed, then the finally block may not execute. Likewise, if the thread executing the try or catch code is interrupted or killed, the finally block may not execute even though the application as a whole continues.

---

• finally 子句 总会被执行(前提：对应的 try子句 执行)
  　
  　下面代码就没有执行 finally 子句：

 public class Test { 
    public static void main(String[] args) { 
        System.out.println("return value of test(): " + test()); 
    } 

    public static int test() { 
        int i = 1; 
        System.out.println("the previous statement of try block"); 
        i = i / 0; 

        try { 
            System.out.println("try block"); 
            return i; 
        }finally { 
            System.out.println("finally block"); 
        } 
     } 
 }/* Output:
        the previous statement of try block 
        Exception in thread "main" java.lang.ArithmeticException: / by zero 
        at com.bj.charlie.Test.test(Test.java:15) 
        at com.bj.charlie.Test.main(Test.java:6)
 *///:~

　　当代码抛出一个异常时，就会终止方法中剩余代码的执行，同时退出该方法的执行。如果该方法获得了一些本地资源，并且这些资源（eg:已经打开的文件或者网络连接等）在退出方法之前必须被回收，那么就会产生资源回收问题。这时，就会用到finally子句，示例如下：

InputStream in = new FileInputStream(...);try{
    ...
}catch (IOException e){
    ...
}finally{
    in.close();
}

---

• finally 子句与控制转移语句的执行顺序

  　　A finally clause can also be used to clean up for break, continue and return, which is one reason you will sometimes see a try clause with no catch clauses. When any control transfer statement is executed, all relevant finally clauses are executed. There is no way to leave a try block without executing its finally clause.

  　　先看四段代码：

// 代码片段1
 public class Test { 
    public static void main(String[] args) {  
        try {  
            System.out.println("try block");  
            return ;  
        } finally {  
            System.out.println("finally block");  
        }  
    }  
 }/* Output:
        try block 
        finally block
 *///:~

// 代码片段2public class Test { 
    public static void main(String[] args) {  
        System.out.println("reture value of test() : " + test()); 
    } 

    public static int test(){ 
        int i = 1; 

        try {  
            System.out.println("try block");  
            i = 1 / 0; 
            return 1;  
        }catch (Exception e){ 
            System.out.println("exception block"); 
            return 2; 
        }finally {  
            System.out.println("finally block");  
        } 
    } 
}/* Output:
        try block 
        exception block 
        finally block 
        reture value of test() : 2
 *///:~

// 代码片段3public class ExceptionSilencer { 
    public static void main(String[] args) { 
        try { 
            throw new RuntimeException(); 
        } finally { 
            // Using ‘return’ inside the finally block 
            // will silence any thrown exception. 
            return; 
        } 
    } 
} ///:~

// 代码片段4class 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) { 
        try { 
            LostMessage lm = new LostMessage(); 
            try { 
                lm.f(); 
            } finally { 
                lm.dispose(); 
            } 
        } catch(Exception e) { 
        System.out.println(e); 
        } 
    } 
} /* Output: 
   A trivial exception 
*///:~

　　从上面的四个代码片段，我们可以看出，finally子句 是在 try 或者 catch 中的 return 语句之前执行的。更加一般的说法是，finally子句 应该是在控制转移语句之前执行，控制转移语句除了 return 外，还有 break 和 continue。另外，throw 语句也属于控制转移语句。虽然 return、throw、break 和 continue 都是控制转移语句，但是它们之间是有区别的。其中 return 和 throw 把程序控制权转交给它们的调用者（invoker），而 break 和 continue 的控制权是在当前方法内转移。

---

　　下面，再看两个代码片段：

// 代码片段5public class Test { 
    public static void main(String[] args) { 
        System.out.println("return value of getValue(): " + getValue()); 
    } 

    public static int getValue() { 
        try { 
                return 0; 
        } finally { 
                return 1; 
            } 
     } 
 }/* Output:
        return value of getValue(): 1
 *///:~

// 代码片段6public class Test { 
    public static void main(String[] args) { 
        System.out.println("return value of getValue(): " + getValue()); 
    } 

    public static int getValue() { 
        int i = 1; 
        try { 
                return i; 
        } finally { 
                i++; 
        } 
    } 
 }/* Output:
         return value of getValue(): 1
 *///:~

　　利用我们上面分析得出的结论：finally子句 是在 try子句 或者 catch子句 中的 return 语句之前执行的。 由此，可以轻松的理解代码片段 5 的执行结果是 1。因为 finally 中的 return 1；语句要在 try 中的 return 0；语句之前执行，那么 finally 中的 return 1；语句执行后，把程序的控制权转交给了它的调用者 main（）函数，并且返回值为 1。
　　
　　那为什么代码片段 6 的返回值不是 2，而是 1 呢？ 按照代码片段 5 的分析逻辑，finally 中的 i++；语句应该在 try 中的 return i；之前执行啊？ i 的初始值为 1，那么执行 i++；之后为 2，再执行 return i；那不就应该是 2 吗？怎么变成 1 了呢？
　　
　　关于 Java 虚拟机是如何编译 finally 子句的问题，有兴趣的读者可以参考《 The JavaTM Virtual Machine Specification, Second Edition 》中 7.13 节 Compiling finally。那里详细介绍了 Java 虚拟机是如何编译 finally 子句。实际上，Java 虚拟机会把 finally 子句作为 subroutine 直接插入到 try 子句或者 catch 子句的控制转移语句之前。但是，还有另外一个不可忽视的因素，那就是在执行 subroutine（也就是 finally 子句）之前，try 或者 catch 子句会保留其返回值到本地变量表（Local Variable Table）中。待 subroutine 执行完毕之后，再恢复保留的返回值到操作数栈中，然后通过 return 或者 throw 语句将其返回给该方法的调用者（invoker）。

　　请注意，前文中我们曾经提到过 return、throw 和 break、continue 的区别，对于这条规则（保留返回值），只适用于 return 和 throw 语句，不适用于 break 和 continue 语句，因为它们根本就没有返回值。

　　下面再看最后三个代码片段：

// 代码片段7public class Test { 
    public static void main(String[] args) { 
        System.out.println("return value of getValue(): " + getValue()); 
    } 

@SuppressWarnings("finally") 
public static int getValue() { 
    int i = 1; 
    try { 
            i = 4; 
        } finally { 
            i++; 
            return i; 
        } 
    } 
 }/* Output:
        return value of getValue(): 5
 *///:~

// 代码片段8public class Test { 
    public static void main(String[] args) { 
        System.out.println("return value of getValue(): " + getValue()); 
    } 

 public static int getValue() { 
    int i = 1; 
    try { 
            i = 4; 
        } finally { 
            i++; 
        } 
        return i; 
     } 
 }/* Output:
        return value of getValue(): 5
 *///:~

// 代码片段9public class Test { 
    public static void main(String[] args) {  
        System.out.println(test());  
    }  

    public static String test() {  
        try {  
            System.out.println("try block");  
            return test1();  
        } finally {  
            System.out.println("finally block");  
        }  
    }  
    public static String test1() {  
        System.out.println("return statement");  
        return "after return";  
    }  
}/* Output:
        try block 
        return statement 
        finally block 
        after return
 *///:~

　　请注意，最后个案例的唯一一个需要注意的地方就是，return test1(); 这条语句等同于 :

 String tmp = test1(); 
 return tmp;

　　因而会产生上述输出。

---

　　特别需要注意的是，在以下4种特殊情况下，finally子句不会被(完全)执行：
　　
　　1）在 finally 语句块中发生了异常;
　　2）在前面的代码中用了 System.exit()【JVM虚拟机停止】退出程序;
　　3）程序所在的线程死亡;
　　4）关闭 CPU;

---

四. 异常的限制

　
　　当覆盖方法时，只能抛出在基类方法的异常说明里列出的那些异常。这意味着，当基类使用的代码应用到其派生类对象时，一样能够工作。
　　

class BaseballException extends Exception {} 
class Foul extends BaseballException {} 
class Strike extends BaseballException {} 

abstract class Inning { 
    public Inning() throws BaseballException {} 
    public void event() throws BaseballException { 
        // Doesn’t actually have to throw anything 
    } 
    public abstract void atBat() throws Strike, Foul; 
    public void walk() {} // Throws no checked exceptions } 

class StormException extends Exception {} 
class RainedOut extends StormException {} 
class PopFoul extends Foul {} 

interface Storm { 
    public void event() throws RainedOut; 
    public 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: 
    public StormyInning() throws RainedOut, BaseballException {} 

    public 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 the base version does: 
    public void event() {} 

    // Overridden methods can throw inherited exceptions: 
    public void atBat() throws PopFoul {} 

    public static void main(String[] args) { 
        try { 
            StormyInning si = new StormyInning(); 
            si.atBat(); 
        } catch(PopFoul e) { 
            System.out.println("Pop foul"); 
        } catch(RainedOut e) { 
            System.out.println("Rained out"); 
        } catch(BaseballException e) { 
            System.out.println("Generic baseball exception"); 
        } 

        // 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) { 
            System.out.println("Strike"); 
        } catch(Foul e) { 
            System.out.println("Foul"); 
        } catch(RainedOut e) { 
            System.out.println("Rained out"); 
        } catch(BaseballException e) { 
            System.out.println("Generic baseball exception"); 
        } 
    } 
} ///:~

• 异常限制对构造器不起作用

  　　子类构造器不必理会基类构造器所抛出的异常。然而，因为基类构造器必须以这样或那样的方式被调用（这里默认构造器将自动被调用），派生类构造器的异常说明必须包含基类构造器的异常说明。

• 派生类构造器不能捕获基类构造器抛出的异常

  　　因为 super() 必须位于子类构造器的第一行，而若要捕获父类构造器的异常的话，则第一行必须是 try 子句，这样会导致编译不会通过。

• 派生类所重写的方法抛出的异常列表不能大于父类该方法的异常列表，即前者必须是后者的子集

  　　通过强制派生类遵守基类方法的异常说明，对象的可替换性得到了保证。需要指出的是，派生类方法可以不抛出任何异常，即使基类中对应方法具有异常说明。也就是说，一个出现在基类方法的异常说明中的异常，不一定会出现在派生类方法的异常说明里。

• 异常说明不是方法签名的一部分

  　　尽管在继承过程中，编译器会对异常说明做强制要求，但异常说明本身并不属于方法类型的一部分，方法类型是由方法的名字及其参数列表组成。因此，不能基于异常说明来重载方法。

---

五. 自定义异常

　　使用Java内置的异常类可以描述在编程时出现的大部分异常情况。除此之外，用户还可以自定义异常。用户自定义异常类，只需继承Exception类即可。
　　
　　在程序中使用自定义异常类，大体可分为以下几个步骤：

　　（1）创建自定义异常类；
　　（2）在方法中通过throw关键字抛出异常对象；
　　（3）如果在当前抛出异常的方法中处理异常，可以使用try-catch语句捕获并处理；否则在方法的声明处通过throws关键字指明要抛出给方法调用者的异常，继续进行下一步操作；
　　（4）在出现异常方法的调用者中捕获并处理异常。

---

六. 异常栈与异常链

1、栈轨迹

　　printStackTrace() 方法可以打印Throwable和Throwable的调用栈轨迹。调用栈显示了由异常抛出点向外扩散的所经过的所有方法，即方法调用序列（main方法 通常是方法调用序列中的最后一个）。

---

2、重新抛出异常

catch(Exception e) { 
System.out.println("An exception was thrown"); 
throw e; 
}

　　既然已经得到了对当前异常对象的引用，那么我们就可以像上面一样将其重新抛出。重新抛出的异常会把异常抛给上一级环境中的异常处理程序，同一个try子句的后续catch子句将被忽略。此外，如果只是把当前异常对象重新抛出，那么printStackTrace() 方法显示的仍是原来异常抛出点的调用栈信息，而并非重新抛出点的信息。要想更新这个信息，可以调用fillInStackTrace() 方法,这将返回一个Throwable对象，它是通过把当前调用栈信息填入原来那个异常对象而建立的。
　　
看下面示例：

public class Rethrowing { 
    public static void f() throws Exception { 
        System.out.println("originating the exception in f()"); 
        throw new Exception("thrown from f()"); 
    } 

    public static void g() throws Exception { 
        try { 
            f(); 
        } catch(Exception e) { 
            System.out.println("Inside g(),e.printStackTrace()"); 
            e.printStackTrace(System.out); 
            throw e; 
        } 
    } 

    public static void h() throws Exception {        try { 
            f(); 
        } catch(Exception e) { 
            System.out.println("Inside h(),e.printStackTrace()"); 
            e.printStackTrace(System.out); 
            throw (Exception)e.fillInStackTrace(); 
        } 
    } 

    public static void main(String[] args) { 
        try { 
            g(); 
        } catch(Exception e) { 
            System.out.println("main: printStackTrace()"); 
            e.printStackTrace(System.out); 
        } 
        try { 
            h(); 
        } catch(Exception e) { 
            System.out.println("main: printStackTrace()"); 
            e.printStackTrace(System.out); 
        } 
    } 
} /* Output: 
    originating the exception in f() 
    Inside g(),e.printStackTrace() 
    java.lang.Exception: thrown from f() 
    at Rethrowing.f(Rethrowing.java:7) 
    at Rethrowing.g(Rethrowing.java:11) 
    at Rethrowing.main(Rethrowing.java:29) 
    main: printStackTrace() 
    java.lang.Exception: thrown from f() 
    at Rethrowing.f(Rethrowing.java:7) 
    at Rethrowing.g(Rethrowing.java:11) 
    at Rethrowing.main(Rethrowing.java:29) 
    originating the exception in f() 
    Inside h(),e.printStackTrace() 
    java.lang.Exception: thrown from f() 
    at Rethrowing.f(Rethrowing.java:7) 
    at Rethrowing.h(Rethrowing.java:20) 
    at Rethrowing.main(Rethrowing.java:35) 
    main: printStackTrace() 
    java.lang.Exception: thrown from f() 
    at Rethrowing.h(Rethrowing.java:24) 
    at Rethrowing.main(Rethrowing.java:35) 
*///:~

---

3、异常链

　异常链：在捕获一个异常后抛出另一个异常，并且希望把原始异常的信息保存下来。
　
　　这可以使用带有cause参数的构造器（在Throwable的子类中，只有Error,Exception和RuntimeException三个类提供了带有cause的构造器）或者使用initcause()方法把原始异常传递给新的异常，使得即使在当前位置创建并抛出了新的异常，也能通过这个异常链追踪到异常最初发生的位置，例如：

class DynamicFieldsException extends Exception {}

...

DynamicFieldsException dfe = new DynamicFieldsException(); 
dfe.initCause(new NullPointerException()); 
throw dfe;

...//捕获该异常并打印其调用站轨迹为：/**
DynamicFieldsException 
at DynamicFields.setField(DynamicFields.java:64) 
at DynamicFields.main(DynamicFields.java:94) 
Caused by: java.lang.NullPointerException 
at DynamicFields.setField(DynamicFields.java:66) 
... 1 more
*/

---

以 RuntimeException 及其子类NullPointerException为例，其源码分别为：
　　
　　RuntimeException 源码包含四个构造器，有两个可接受cause:

public class RuntimeException extends Exception {
    static final long serialVersionUID = -7034897190745766939L;    
    /** Constructs a new runtime exception with <code>null</code> as its
     * detail message.  The cause is not initialized, and may subsequently be
     * initialized by a call to {@link #initCause}.
     */
    public RuntimeException() {    super();
    }    /** Constructs a new runtime exception with the specified detail message.
     * The cause is not initialized, and may subsequently be initialized by a
     * call to {@link #initCause}.
     *
     * @param   message   the detail message. The detail message is saved for 
     *          later retrieval by the {@link #getMessage()} method.
     */
    public RuntimeException(String message) {    super(message);
    }    /**
     * Constructs a new runtime exception with the specified detail message and
     * cause.  <p>Note that the detail message associated with
     * <code>cause</code> is <i>not</i> automatically incorporated in
     * this runtime exception&#39;s detail message.
     *
     * @param  message the detail message (which is saved for later retrieval
     *         by the {@link #getMessage()} method).
     * @param  cause the cause (which is saved for later retrieval by the
     *         {@link #getCause()} method).  (A <tt>null</tt> value is
     *         permitted, and indicates that the cause is nonexistent or
     *         unknown.)
     * @since  1.4
     */
    public RuntimeException(String message, Throwable cause) {        super(message, cause);
    }    /** Constructs a new runtime exception with the specified cause and a
     * detail message of <tt>(cause==null ? null : cause.toString())</tt>
     * (which typically contains the class and detail message of
     * <tt>cause</tt>).  This constructor is useful for runtime exceptions
     * that are little more than wrappers for other throwables.
     *
     * @param  cause the cause (which is saved for later retrieval by the
     *         {@link #getCause()} method).  (A <tt>null</tt> value is
     *         permitted, and indicates that the cause is nonexistent or
     *         unknown.)
     * @since  1.4
     */
    public RuntimeException(Throwable cause) {        super(cause);
    }
}

　　NullPointerException 源码仅包含两个构造器，均不可接受cause:

public class NullPointerException extends RuntimeException {
    /**
     * Constructs a <code>NullPointerException</code> with no detail message.
     */
    public NullPointerException() {    super();
    }    /**
     * Constructs a <code>NullPointerException</code> with the specified 
     * detail message. 
     *
     * @param   s   the detail message.
     */
    public NullPointerException(String s) {    super(s);
    }
}

注意：

　　所有的标准异常类都有两个构造器：一个是默认构造器；另一个是接受字符串作为异常说明信息的构造器。

---

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung und Analyse des Java-Ausnahmemodells (Bild). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!