Ausnahmebehandlung, Architektur- und Nutzungsvorschläge in Java

Java -Ausnahmen sind ein von Java bereitgestellter Konsistenzmechanismus, um Fehler zu identifizieren und auf Reaktion zu reagieren.
Der Java -Ausnahmemechanismus kann den Ausnahmebehandlungscode im Programm von normaler Geschäftsordnung trennen, sicherstellen, dass der Programmcode eleganter ist und die Programmrobustheit verbessert. Wenn Sie Ausnahmen effektiv verwenden, kann die Ausnahme diese drei Fragen eindeutig beantworten: der Ausnahmeart Answers "Was" und die Ausnahmestapel Trace Antworten "Wo" und die Ausnahmeinformationen Antworten "Warum" werden geworfen.
Mehrere Schlüsselwörter, die im Java -Ausnahmemechanismus verwendet werden: Versuchen Sie, schließlich werfen, werfen, werfen.

 public class Demo1 {public static void main (String [] args) {try {int i = 10/0; System.out.println ("i ="+i); } catch (AritheMeticexception e) {System.out.println ("gefangene Ausnahme"); System.out.println ("e.getMessage ():" + e.getMessage ()); System.out.println ("e.ToString ():" + e.toString ()); System.out.println ("e.printstacktrace ():"); E. printstacktrace (); }}}

Auslaufergebnisse:

 Gefangene Exectee.getMessage (): / von Zeroe.toString (): java.lang.arithmeTexception: / by zeroe.printstacktrace (): java.lang.arithmexception: / by Zero bei Demo1.main (Demo1.java:6)

Die Ergebnisbeschreibung: Es gibt eine Operation mit einem Divisor von 0 im Try -Anweisung -Block, und die Operation wird eine Ausnahme von java.lang.arithmeMexception auswerfen. Durch Fang wird die Ausnahme gefangen.
Bei der Beobachtung der Ergebnisse fanden wir, dass System.out.println ("i ="+i) nicht ausgeführt wurde. Dies bedeutet, dass nach einer Ausnahme im Block Anweisungsblock der Versuch der verbleibende Inhalt im Block Anweisungsblock nicht mehr ausgeführt wird.
Beispiel 2: Verstehen Sie die grundlegende Verwendung von endlich
Basierend auf "Beispiel One" fügen wir endgültig Aussagen hinzu.

 public class Demo2 {public static void main (String [] args) {try {int i = 10/0; System.out.println ("i ="+i); } catch (AritheMeticexception e) {System.out.println ("gefangene Ausnahme"); System.out.println ("e.getMessage ():" + e.getMessage ()); System.out.println ("e.ToString ():" + e.toString ()); System.out.println ("e.printstacktrace ():"); E. printstacktrace (); } endlich {system.out.println ("endlich rennen"); }}}

Auslaufergebnisse:

 Gefangene Exception.getMessage (): / by Zeroe.toString (): java.lang.arithmeTexception: / by zeroe.printstacktrace (): java.lang.arithmeTexception: / by Zero bei Demo2.main (Demo2.java:6) leiten schließlich laufend endlich

Ergebnisse: Schließlich wurde Anweisungsblock ausgeführt.
Beispiel 3: Verstehen Sie die grundlegende Verwendung von Würfen und Würfen
Würfe werden verwendet, um geworfene Ausnahmen zu deklarieren, während Wurf verwendet wird, um Ausnahmen zu werfen.

 Klasse myException erweitert die Ausnahme {public myException () {} public myException (String msg) {Super (msg); }} public class Demo3 {public static void main (String [] args) {try {test (); } catch (myException e) {System.out.println ("Catch meine Ausnahme"); E. printstacktrace (); }} public static void test () löscht myException {try {int i = 10/0; System.out.println ("i ="+i); } catch (AritheMeticexception e) {neue myexception ("this is myException"); }}}

Auslaufergebnisse:

 Catch My ExceptionMyException: Dies ist myException bei Demo3.test (Demo3.java:24) bei Demo3.main (Demo3.java:13)

Ergebnisse: MyException ist eine Unterklasse, die von Ausnahme geerbt wurde. Die Arithmeticexception -Ausnahme (Teiler ist 0) wird im Block von Test -Anweisungen von Test () generiert, und die Ausnahme wird im Fang gefangen; Dann wird eine Myexception -Ausnahme ausgeworfen. Die Main () -Methode erfasst die MyException, die in test () geworfen wurde.

Java -Ausnahme -Framework
Java Exception Architecture Diagramm:

1. Throwable
Throwable ist eine Superklasse aller Fehler oder Ausnahmen in der Java -Sprache.
Throwable enthält zwei Unterklassen: Fehler und Ausnahme. Sie werden normalerweise verwendet, um anzuzeigen, dass eine Anomalie aufgetreten ist.
Throwable enthält Schnappschüsse des Threads, das den Stapel ausführt, wenn sein Thread erstellt wird. Es bietet Schnittstellen wie PrintStacktrace (), um Informationen wie Stack -Trace -Daten zu erhalten.

2. Ausnahme
Ausnahme und ihre Unterklassen sind eine Form von Throwable, die auf die Bedingungen hinweist, die eine angemessene Anwendung erfassen möchte.

3.. RunTimeException
RunTimeException ist eine Superklasse, die Ausnahmen während des normalen Betriebs der virtuellen Java -Maschine ausführen kann.
Der Compiler überprüft keine Ausnahmen von RunTimeException. Wenn der Divisor beispielsweise Null ist, wird eine Arithmeticexception -Ausnahme ausgelöst. RunTimeException ist eine Superklasse von Arithmexception. Wenn der Code einen Teil von Null hat, kann er auch kompiliert werden, wenn er "nicht durch Throws -Deklaration geworfen wird" oder "wird nicht durch Versuch gehandhabt ... Fang ...". Dies ist das, was wir sagen "Der Compiler wird nicht nach RunTimeException -Ausnahmen suchen"!
Wenn der Code eine RunTimeException -Ausnahme generiert, muss er vermieden werden, indem der Code geändert wird. Wenn der Divisor beispielsweise Null ist, müssen Sie diese Situation durch Code vermeiden!

4. Fehler
Wie eine Ausnahme ist der Fehler auch eine Unterklasse von Throwable. Es wird verwendet, um ernsthafte Probleme anzuzeigen, die eine angemessene Anwendung nicht zu fangen versuchen sollte, und die meisten derartigen Fehler sind außergewöhnliche Bedingungen.
Wie RunTimeException wird der Compiler nicht nach einem Fehler prüfen.
Java unterteilt die Throwable -Struktur in drei Typen: Checked Exception (Checked Exception), Laufzeitausnahme (RunTimeException) und Fehler (Fehler).

(1) Laufzeitausnahme
Definition: RunTimeException und ihre Unterklassen werden als Laufzeitausnahmen bezeichnet.
Merkmale: Der Java -Compiler wird es nicht überprüfen. Das heißt, wenn eine solche Ausnahme im Programm auftritt, wenn sie "nicht durch die Throw-Erklärung geworfen wird" oder "nicht mit der Aussageerklärung gefangen" wird, wird sie immer noch kompiliert und bestanden. Zum Beispiel sind die ArithmeMexception-Ausnahme, die bei Null erzeugt wird, die IndexoutOfboundSexception-Ausnahme, die bei außerhalb der Grenzen generiert wird.
Obwohl der Java-Compiler nicht auf Ausnahmen von Laufzeit überprüft, können wir sie auch mit Würfen deklarieren und durchführen oder durch Try-Catch erfassen.
Wenn eine Laufzeitausnahme generiert wird, muss sie vermieden werden, indem der Code geändert wird. Wenn der Divisor beispielsweise Null ist, müssen Sie diese Situation durch Code vermeiden!

(2) Überprüfung der Ausnahme
Definition: Die Ausnahmeklasse selbst und andere Unterklassen in den Unterklassen der Ausnahme, mit Ausnahme der "Laufzeitausnahme" werden alle als geprüfte Ausnahmen betrachtet.
Merkmale: Der Java -Compiler wird es überprüfen. Solche Ausnahmen werden entweder deklariert und durch Würfe geworfen oder durch Try-Catch erfasst, andernfalls können sie nicht kompiliert werden. Beispielsweise ist ClonenotsuptedEdException eine geprüfte Ausnahme. Wenn ein Objekt durch die Schnittstelle von Clone () kloniert wird und die entsprechende Klasse des Objekts die klonbare Schnittstelle nicht implementiert, wird eine ClonenotsupportedException geworfen.
Die Überprüfung von Ausnahmen kann normalerweise wiederhergestellt werden.

(3) Fehler
Definition: Fehlerklasse und ihre Unterklassen.
Funktionen: Wie bei Laufzeitausnahmen prüft der Compiler nicht auf Fehler.
Ein Fehler tritt auf, wenn unzureichende Ressourcen, Einschränkungen oder andere Bedingungen nicht genügend Ressourcen vorliegen, die nicht weiter von anderen Programmen ausgeführt werden können. Das Programm selbst kann diese Fehler nicht beheben. Zum Beispiel ist VirtualMachineError ein Fehler.
Laut Java Convention sollten wir keine neuen Fehlerunterklassen implementieren!
Welches sollten wir für die oben genannten drei Strukturen eine Ausnahme oder einen Fehler machen? Die in "effektive Java" angegebene Empfehlung lautet: Verwenden Sie überprüfte Ausnahmen für Bedingungen, die wiederhergestellt werden können, und verwenden Sie Laufzeitausnahmen für Programmfehler.

Mehrere Vorschläge zur Ausnahmebehandlung

Artikel 1: Verwenden Sie Ausnahmen nur für abnormale Situationen
Empfehlung: Ausnahmen sollten nur für abnormale Bedingungen verwendet werden und sie sollten niemals für normale Kontrollströme verwendet werden.
Die Erläuterung erfolgt durch Vergleich der beiden folgenden Codes.
Code 1

 Versuchen Sie {int i = 0; while (true) {arr [i] = 0; i ++; }} catch (indexoutOfBoundSexception e) {} Code 2For (int i = 0; i <arr.length; i ++) {arr [i] = 0;}

Der Zweck beider Codes ist es, über das Array des Arrays zu iterieren und den Wert jedes Elements im Array auf 0 festzulegen. Code 1 endet mit Ausnahme, was sehr schwer zu verstehen scheint, Code 2 endet nach Array -Grenzen. Wir sollten es vermeiden, Code 1 aus drei Hauptgründen zu verwenden:
Das ursprüngliche Design von Ausnahmemechanismen gilt für abnormale Situationen, sodass nur wenige JVM -Implementierungen versuchen, ihre Leistung zu optimieren. Daher ist der Overhead des Erstellens, Werfens und Fangens von Ausnahmen teuer.
Wenn Sie den Code in die Rückgabe von Try-Catch-Renditen einsetzen, wird die Implementierung des JVM bestimmte spezifische Optimierungen, die möglicherweise durchgeführt werden können, implementiert.
Das Standardmuster von Traversing -Arrays führt nicht zu redundanten Überprüfungen, und einige moderne JVM -Implementierungen optimieren sie.
In der Tat sind ausnahmebasierte Modi viel langsamer als Standardmodi. Der Testcode lautet wie folgt:

 public class Rating1 {private static int [] arr = new int [] {1,2,3,4,5}; private statische int Größe = 10000; public static void main (String [] args) {long s1 = system.currentTimemillis (); für (int i = 0; i <size; i ++) endbyrange (arr); long e1 = system.currentTimemillis (); System.out.println ("Endbyrange Zeit:"+(e1-s1)+"ms"); long s2 = system.currentTimemillis (); für (int i = 0; i <size; i ++) endByException (arr); long e2 = system.currentTimemillis (); System.out.println ("EndbyException-Zeit:"+(e2-s2)+"ms"); } // Überqueren Sie das Array: private statische void endByException (int [] arr) {try {int i = 0; while (true) {arr [i] = 0; i ++; //System.out.println("endbyrange: arr ["+i+"] = "+arr [i]); }} catch (indexoutOfBoundSexception e) {}} // Übertragen Sie das Array: private statische void endbyrange (int [] arr) {für (int i = 0; i <arr.length; i ++) {arr [i] = 0; //System.out.println("endByException: arr ["+i+"] = "+arr [i]); }}}

Auslaufergebnisse:

 Endbyrange Zeit: 8msendByException Zeit: 16ms

Das Ergebnis zeigt, dass die Geschwindigkeit der Ausnahme viel langsamer ist, als ein Array auf gewöhnliche Weise zu durchqueren!

Artikel 2: Verwenden Sie überprüfte Ausnahmen für wiederherstellbare Bedingungen und verwenden Sie die Laufzeitausnahmen für Programmfehler.

Der Unterschied besteht darin, dass der Java -Compiler nach "geprüften Ausnahmen" überprüft und nicht nach "Laufzeitausnahmen" prüft.
Das heißt, für die geprüfte Ausnahme wird sie entweder deklariert und durch Würfe geworfen oder durch Versuchs-Catch erfasst, sonst kann es nicht kompiliert werden. Für Laufzeitausnahmen, wenn sie "nicht durch die Erklärung der Würfe geworfen werden" oder "nicht mit Versuchserklärung gefangen" werden, werden sie immer noch zusammengestellt und bestanden. Obwohl der Java-Compiler nicht auf Ausnahmen von Laufzeit überprüft, können wir die Ausnahme auch durch Würfe erklären oder sie durch Try-Catch fangen.
RithmeMexception (z. B. Divisor ist 0), IndexoutOfBoundSexception (z. B. Array außerhalb der Grenzen) usw. sind alle Ausnahmen von Laufzeit. Für diese Ausnahme sollten wir dies vermeiden, indem wir den Code ändern. Für die geprüfte Ausnahme kann das Programm wiederhergestellt werden, um die Verarbeitung durchzuführen. Angenommen, ein Benutzer speichert beispielsweise keine ausreichende Anzahl von Anrufen, wird er versagen, wenn er versucht, einen Anruf bei einem Gehaltsanruf zu tätigen. somit eine geprüfte Ausnahme auswerfen.

Artikel 3: Vermeiden Sie den unnötigen Gebrauch von überprüften Ausnahmen
"Censored Exception" ist ein gutes Merkmal von Java. Im Gegensatz zum Rückgabecode zwingen "geprüfte Ausnahmen" den Programmierer, sich mit Ausnahmebedingungen zu befassen, was die Zuverlässigkeit des Programms erheblich verbessert.
Eine übermäßige Verwendung überprüfter Ausnahmen kann jedoch die API sehr unpraktisch machen. Wenn eine Methode eine oder mehrere überprüfte Ausnahmen ausführt, muss der Code, der die Methode aufruft, diese Ausnahmen in einer oder mehreren Catch -Anweisungsblöcken verarbeiten oder sie müssen durch die Erklärung der Würfe geworfen werden. Egal, ob es durch Fang behandelt wird oder durch Würfelerklärungen geworfen wird, es fügt Programmierern eine nicht gefährliche Belastung hinzu.
Zwei Bedingungen müssen für "geprüfte Ausnahmen" erfüllt sein: Erstens kann das Auftreten von Ausnahmebedingungen nicht verhindern, wenn die API korrekt verwendet wird. Zweitens können Programmierer, die die API verwenden, nach einer Ausnahme nützliche Maßnahmen zur Verarbeitung des Programms ergreifen.

Artikel 4: Versuchen Sie, Standardausnahmen zu verwenden
Die Wiederverwendung von Code ist der Anwaltschaft wert, dies ist eine gemeinsame Regel, und Ausnahmen sind keine Ausnahme. Die Wiederverwendung bestehender Ausnahmen bietet mehrere Vorteile:
Erstens erleichtert Ihre API das Erlernen und Gebrauch, da sie mit den Redewendungen übereinstimmt, mit denen Programmierer vertraut sind.
Zweitens sind für Programme, die diese APIs verwenden, besser lesbar, da sie nicht mit Ausnahmen gefüllt sind, die den Programmierern nicht vertraut sind.
Drittens sind je weniger Ausnahmeklassen, desto kleiner die Speicherverwendung und je kleiner die Zeit, die für die Nachdruck dieser Klassen aufgewendet wird.
Einige der Java -Standardausnahmen werden häufig ausgenommen. Die folgende Tabelle:

Obwohl sie bisher die am häufigsten wiederverwendeten Ausnahmen von Java -Plattformbibliotheken sind, können auch andere Ausnahmen unter Lizenzbedingungen wiederverwendet werden. Wenn Sie beispielsweise arithmetische Objekte wie komplexe Zahlen oder Matrizen implementieren möchten, wäre es sehr angemessen, die Arithmeticexception und NumberFormatexception wiederzuverwenden. Wenn eine Ausnahme auf Ihre Bedürfnisse entspricht, zögern Sie nicht, sie zu verwenden, aber Sie müssen sicherstellen, dass die Ausnahmezustand mit den in der Dokumentation für die Ausnahme beschriebenen Bedingungen übereinstimmt. Diese Wiederverwendung muss auf Semantik basieren, nicht auf dem Namen!
Stellen Sie schließlich sicher, dass Sie sich klarstellen müssen, dass es keine Regel gibt, die bei der Auswahl der Ausnahme nach Wiederverwendung befolgt werden muss. Angenommen, es gibt eine Methode zum Handlungsvorgang, und der Parameter (Handwerk) ist beispielsweise die Anzahl der Karten, die in einer Hand angegeben werden müssen. Angenommen, der Anrufer übergibt einen Wert in diesem Parameter, der größer ist als die verbleibende Anzahl von Karten für das gesamte Deck. Dann kann diese Situation als illegalArgumentException (der Wert von Handsize zu groß) oder als IllegalStateException interpretiert werden (das Kartenobjekt hat zu wenige Karten in Bezug auf die Anfrage des Kunden).

Artikel 5: Die geworfene Ausnahme sollte für die entsprechende Abstraktion geeignet sein
Diese Situation kann überwältigend sein, wenn eine mit einer Methode ausgelöste Ausnahme keine offensichtliche Korrelation mit der von ihr ausgeführten Aufgabe hat. Dies geschieht häufig, wenn eine Methode eine Ausnahme durch eine Abstraktion auf niedriger Ebene ausgibt. In diesem Fall verwirrt es nicht nur, sondern auch "Verschmutzungen" -Mapis.
Um dieses Problem zu vermeiden, sollte die Implementierung auf hoher Ebene die Ausnahme auf niedriger Ebene aufnehmen und eine Ausnahme ausführen, die gemäß der hochrangigen Abstraktion eingeführt werden kann. Diese Praxis wird als "Ausnahmeübersetzung" bezeichnet.
Beispielsweise lautet die Java Collection Framework AbstractSequentialList get () -Methode wie folgt (basierend auf JDK1.7.0_40):

 public e get (int index) {try {return listIterator (index) .Next (); } catch (NoSuchelementException exc) {throf New IndexoutOfBoundSexception ("Index:"+Index); }}

ListIterator (Index) gibt das Listiterator -Objekt zurück. Wenn Sie die nächste () Methode des Objekts aufrufen, kann eine NoSuchelementException -Ausnahme ausgelöst werden. Bei der Get () -Methode wird es verwirrend sein, eine NoSuchelementException -Ausnahme auszusetzen. Get () erfasst NoSuchelementException und wirft eine IndexoutOfboundSexception -Ausnahme aus. Das heißt, es entspricht der Konvertierung der NoSuchelementException in die IndexoutOfboundSexception -Ausnahme.

Artikel 6: Die von jeder Methode ausgelöste Ausnahme muss dokumentiert werden
So deklarieren Sie die geprüfte Ausnahme separat und verwenden Sie das @Throws -Tag von Javadoc, um die Bedingungen für jede Ausnahme genau aufzuzeichnen.
Wenn viele Methoden in einer Klasse aus dem gleichen Grund die gleiche Ausnahme auswerfen, ist es akzeptabel, in den Dokumentkommentaren dieser Klasse Dokumentation für diese Ausnahme zu machen, anstatt für jede Methode einzeln zu dokumentieren.

Artikel 7: Fügen Sie die Fehlermeldung zur Detail-Meldung ein
Kurz gesagt, wenn wir eine Ausnahme anpassen oder auswerfen, sollten wir Informationen zum Fehler in Verbindung bringen.
Wenn ein Programm aufgrund einer ungewöhnlichen Ausnahme fehlschlägt, druckt das System automatisch die Stapelspur der Ausnahme aus. Enthält eine String -Darstellung der Ausnahme in der Stapelspur. Normalerweise enthält es den Klassennamen der Ausnahmeklasse zusammen mit der folgenden detaillierten Nachricht.

Artikel 8: Streben Sie sich bemüht, die Atomizität beim Scheitern aufrechtzuerhalten
Wenn ein Objekt eine Ausnahme ausführt, erwarten wir immer, dass das Objekt in einem gut definierten verfügbaren Zustand bleibt. Dies ist besonders wichtig für die geprüfte Ausnahme, da der Anrufer normalerweise erwartet, sich von der geprüften Ausnahme zu erholen.
Im Allgemeinen sollte ein fehlgeschlagener Methodenaufruf das Objekt in "seinem Zustand, bevor es genannt wurde" aufbewahren. Methoden mit solchen Attributen werden als "Fehleratomic" bezeichnet. Es kann verstanden werden, dass das Scheitern die Atomizität immer noch aufrechterhält. Es gibt verschiedene Möglichkeiten, wie ein Objekt "gescheiterte Atomizität" aufrechterhält:
(1) Entwerfen Sie ein nicht-tankeres Objekt.
(2) Für Methoden, die Operationen an veränderlichen Objekten ausführen, besteht die häufigste Möglichkeit, "fehlgeschlagene Atomizität" zu erhalten, die Gültigkeit der Parameter vor der Durchführung des Vorgangs. Wie folgt (POP -Methode in stack.java):

 public Object pop () {if (size == 0) werfen neue leerStackexception (); Objektergebnis = Elemente [-Größe]; Elemente [Größe] = NULL; Rückgabeergebnis;}

(3) Ähnlich wie bei der vorherigen Methode kann die Berechnungsverarbeitung so angepasst werden, dass ein möglicher Fehler des Berechnungsteils auftritt, bevor der Objektzustand geändert wird.
(4) Schreiben Sie einen Wiederherstellungscode, um die Fehler während des Betriebs zu erläutern und das Objekt vor Beginn der Operation wieder in den Zustand zu rollen.
(5) Führen Sie einen Vorgang für eine temporäre Kopie des Objekts durch und kopieren Sie nach Abschluss des Vorgangs das Ergebnis in der temporären Kopie in das ursprüngliche Objekt.
"Die Aufrechterhaltung der gescheiterten Atomizität eines Objekts ist zwar das gewünschte Ziel, ist zwar nicht immer möglich. Wenn beispielsweise mehrere Threads versuchen, ohne ordnungsgemäße Synchronisationsmechanismen gleichzeitig auf ein Objekt zuzugreifen, kann das Objekt in einem inkonsistenten Zustand gelassen werden.
Selbst in Situationen, in denen "gescheiterte Atomizität" erreicht werden kann, wird dies nicht immer erwartet. Bei einigen Operationen kann es den Overhead oder die Komplexität erheblich erhöhen.
Die allgemeine Regel lautet: Als Teil der Methodenspezifikation sollte keine Ausnahme den Status des Objekts ändern, bevor die Methode aufgerufen wird. Wenn diese Regel verletzt wird, sollte die API -Dokumentation eindeutig angeben, in welchem ​​Zustand das Objekt sein wird.

Artikel 9: Ignorieren Sie keine Ausnahmen
Wenn ein API -Designer erklärt, dass eine Methode eine Ausnahme auslöst, versuchen sie, etwas zu veranschaulichen. Also, bitte ignoriere es nicht! Der Code, um Ausnahmen zu ignorieren, lautet wie folgt:

 Versuchen Sie {...} catch (einige exception e) {}

Ein leerer Fangblock lässt die Ausnahme seinen angemessenen Zweck nicht erreichen. Der Zweck der Ausnahme ist es, Sie zu zwingen, mit abnormalen Bedingungen umzugehen. Das Ignorieren einer Ausnahme ist wie das Ignorieren eines Feueralarmsignals - Wenn das Feueralarmsignal ausgeschaltet ist, sieht niemand das Feueralarmsignal, wenn das reale Feuer auftritt. Zumindest sollte der Fangblock eine Beschreibung enthalten, die erklärt, warum es angemessen ist, diese Ausnahme zu ignorieren.