1 / 63

Grundlagen der Informatik I Thema 16: Ausnahmebehandlung

Grundlagen der Informatik I Thema 16: Ausnahmebehandlung. Prof. Dr. Max Mühlhäuser Dr. Guido Rößling. Übersicht. Fehler und deren Klassifizierung Fehlerbehandlung ohne eigenständige Sprachmechanismen und deren Probleme

macon
Télécharger la présentation

Grundlagen der Informatik I Thema 16: Ausnahmebehandlung

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Grundlagen der Informatik IThema 16: Ausnahmebehandlung Prof. Dr. Max Mühlhäuser Dr. Guido Rößling

  2. Übersicht • Fehler und deren Klassifizierung • Fehlerbehandlung ohne eigenständige Sprachmechanismen und deren Probleme • Grundkonzepte der Fehlerbehandlung mit eigenständigen Sprachmechanismen am Beispiel von Java • Vorteile der Fehlerbehandlung mit eigenständigen Sprachmechanismen am Beispiel von Java • Zusammenfassung

  3. Lexikalische Fehler: Falsche oder unbekannte Worte // ... int[] result = neuint[5]; result.size(); // ... Syntaxfehler: Falsche Anordnung von Worten //... move(); public static void main(String[] args) { // ... } //... Klassifikation von Fehlern Lexikalische und syntaktische Fehler werden vom Compiler entdeckt und signalisiert

  4. Laufzeitfehler: ein Ereignis, das während des Ablaufs eines Programms vorkommt und den normalen Kontrollfluss der Anweisungen stört  Fehlerterminierung Division durch 0 Ein Grafikobjekt soll gezeichnet werden, existiert aber nicht Intentionsfehler: Programm läuft, aber mit unerwünschtem Ergebnis Klassifikation von Fehlern

  5. Umgang mit Fehlern ist ein wichtiger Teil der Softwareentwicklung: Qualitätszusicherung! Die übliche Reaktion auf nicht abgefangene Ausnahmesituationen: Programmabsturz! Das kann manchmal besser sein als fehlerhafte Ereignisse, die für eine lange Zeit unentdeckt bleiben. Komplexe Programme/verteilte Anwendungen ohne jede Reaktion auf Ausnahmen sind nicht akzeptabel. Telekommunikationssysteme Steuerungssysteme, z.B. Raketen, Kernkraftwerke Programme, die tolerant (gracefully) mit Fehlern umgehen, werden robustgenannt. Fehlerbehandlung

  6. Diese Vorlesung  Laufzeitfehler abfangen und beheben Schwerwiegende versus leichtgewichtige Fehler Nächste Vorlesung  Intentionsfehler: Testen/verifizieren, dass die Software das tut, was sie tun sollte Bug: Bezeichnung für alle Programmfehler Ursprung: Im einem Computer löste ein totes Insekt (engl. Bug) in einem Relais einen Fehler aus Meist schwer zu finden, „100% Bug-free“ – unmöglich Debugging = Fehlersuche Beide Worte gehen auf Grace Murray Hopper ( T12.28) zurück Fehlerbehandlung, Bug, Debugging

  7. Schwerwiegende Laufzeitfehler (Error) • Zwei Sorten von schwerwiegenden Laufzeitfehlern • Systemfehler: Fehler in der Java-VM, Speichermangel, … • Nicht „Schuld“ von Anwendungsprogrammierer • Können prinzipiell nicht abgefangen werden und führen direkt zum Programmabsturz • Programmierfehler, nach denen eine Programmfortsetzung nicht mehr möglich ist • Eine benötigte Klasse ist nicht vorhanden

  8. Leichtgewichtige Fehler • Ausnahme (Exception)können innerhalb des Programms abgefangen werden; Programmfortsetzung ist möglich. Problem: Eingabe eines fehlerhaften Dateinamens durch Benutzer Behebung: Neueingabe verlangen Problem: Fehlerhafte Daten in einer Datei, die ignoriert werden können, z.B. nicht interpretierbare Bild- oder Audiosignale Behebung: Ignorieren Problem: Zusammenbruch einer Netzverbindung Behebung: Neuaufbau der Verbindung

  9. Einige typische Ausnahmen publicvoidprintPerson() { Person aPerson = null; // ... printName(aPerson); // ... } publicvoidprintName(Person p) { System.out.println(p.name); } • Problem: Sende eine Nachricht an "null" • Ergebnis: NullPointerException • Zugriff auf eine Methode oder Instanzvariable eines nicht-existierenden Objekts (null) • Die Existenz eines Objekts sollte vor dem Zugriff geprüft werden!

  10. int[] matrikelNummern = newint[27]; for (int i = 0; i <= 27; i++) System.out.println(matrikelNummern[i]); Einige typische Ausnahmen • Problem: illegaler Array-Zugriff mit i == 27 • Ergebnis: ArrayIndexOutOfBoundsException • Gültig sind nur Positionen i mit 0 <= i < array.length • Besonders trickreich bei Aufrufparametern • Immer erst überprüfen, wie viele Argumente es gibt (args.length)

  11. Einige typische Ausnahmen publicstaticvoidmain(String[] args) { intcount; count = Integer.parseInt(args[1]); // ... } Dieser Zugriff führt potentiell zu mehreren Fehlern! Problem 1: illegaler Array-Zugriff, falls keine Parameter an das Programm übergeben wurden. In diesem Fall hat args keine Elemente – Zugriff auf args[1] schlägt fehl. Ergebnis: ArrayIndexOutOfBoundsException Problem 2: Versuch eine Nicht-Zahl zu parsen, falls args[1] z.B. "Hello"ist. Text kann nicht in eine Zahl umgewandelt werden. Ergebnis: NumberFormatException

  12. Fehlerbehandlung • Zwei Arten von Fehlerbehandlung: • Ohne eigenständige Sprachmechanismen • In Sprachen wie C oder Pascal • Mit eigenständigen Sprachmechanismen • In Sprachen wie etwa Ada, Smalltalk, Java • Im folgenden werden wir • Die Probleme der Sprachen ohne dedizierte Fehlerbehandlungsmechanismen diskutieren • Fehlerbehandlung mit dedizierten Sprachmechanismen und deren Vorteile am Beispiel von Java vorstellen

  13. Übersicht • Fehler und deren Klassifizierung • Fehlerbehandlung ohne eigenständige Sprachmechanismen und deren Probleme • Grundkonzepte der Fehlerbehandlung mit eigenständigen Sprachmechanismen am Beispiel von Java • Vorteile der Fehlerbehandlung mit eigenständigen Sprachmechanismen am Beispiel von Java • Zusammenfassung

  14. Fehlerbehandlung ohne Sprachmechanismen • Zwei Möglichkeiten von Fehlersignalisierung: • Programmabbruch (!) - Prozeduren/ Funktionen einer Sprache, melden keine Fehler • Zugriffsversuch auf eine nicht vorhandene Datei endete in „alten“ Versionen von Pascal mit einem Programmabsturz. • Fehler werden signalisiert • Meist über unübliche Rückgabewerte von Methoden • z.B. –1 statt positiver Zahl • Abfangen und Behandlung von Fehlern: • Fehlerbehandlung wird (vom Programmierer) ignoriert • Fehler werden behandelt, z.B. über Fallunterscheidungen

  15. Fehlerbehandlung ohne Sprachmechanismen • Wir betrachten den Fall: • Unübliche Rückgabewerte zur Signalisierung • Bedingungslogik zur Behandlung • Problem:Keine Trennung der normalen Verarbeitung von der Fehlerbehandlung • Betrachten wir eine Funktion (in Pseudocode), die eine ganze Datei von der Festplatte in den Hauptspeicher liest. readFile { open the file; determine its size; allocate that much memory; read the file into memory; close the file; }

  16. Fehlerbehandlung ohne Sprachmechanismen • Auf dem ersten Blick wirkt die Funktion sehr simpel • Aber sie ignoriert alle möglichen Fehler: • Die Datei kann nicht geöffnet werden. • Die Länge der Datei kann nicht festgestellt werden. • Es ist nicht genug Platz im Hauptspeicher vorhanden. • Lesen von der Datei schlägt fehl. • Die Datei kann nicht geschlossen werden. • Um diese Fälle zu behandeln, müssen wir eine Menge Code hinzufügen, wie die folgende Implementierung zeigt.

  17. Fehlerbehandlung ohne Sprachmechanismen errorCodeTypereadFile { initializeerrorCode = 0; open thefile; if (theFileIsOpen) { determinethelengthofthefile; if (gotTheFileLength) { allocatethatmuchmemory; if (gotEnoughMemory) { readthefileintomemory; if (readFailed) { errorCode = -1; } } else { errorCode = -2; } } else { errorCode = -3; } closethefile; if (theFileDidntClose && errorCode == 0) { errorCode = -4; } else { errorCode = errorCode && -4; } } else { errorCode = -5; } returnerrorCode; }

  18. Fehlerbehandlung ohne Sprachmechanismen • Mit eingebauter Fehlerbehandlung bekommen wir 29 anstelle von 7 Zeilen Code - ein Faktor von fast 400%! • Der Ursprungscode geht in dem Code für Entdeckung, Signalisierung und Behandlung von Fehlern verloren. • Der logische Fluss des Codes ist verloren gegangen, was die Beurteilung, ob der Code das Richtige macht, sehr erschwert. • Wird die Datei tatsächlich in dem Fall geschlossen, dass es nicht genügend Speicherplatz gibt? • Noch schwieriger wird es, wenn die Funktion später modifiziert wird!

  19. Fehlerbehandlung ohne Sprachmechanismen • Schlussfolgerung: Konflikt zwischen Zuverlässigkeit und Übersichtlichkeit • Werden Fehler behandelt, so entstehen unübersichtliche Programmstrukturen (z.B. viele Fallunterscheidungen) • Werden Fehler ignoriert, so ist die Zuverlässigkeit des Programms nicht sichergestellt • Eine Ausnahmebehandlung ohne eigenständige • Sprachkonstrukte hat sich nicht bewährt!

  20. Übersicht • Fehler und deren Klassifizierung • Fehlerbehandlung ohne eigenständige Sprachmechanismen und deren Probleme • Grundkonzepte der Fehlerbehandlung mit eigenständigen Sprachmechanismen am Beispiel von Java • Vorteile der Fehlerbehandlung mit eigenständigen Sprachmechanismen am Beispiel von Java • Zusammenfassung

  21. Ausnahmebehandlung in Java • In Java werden Ausnahmen als Objekte dargestellt. • Der Java-Compiler erzwingt die Behandlung von bestimmten Typen von Fehlern. • Wenn ein Fehler während der Ausführung einer Methode auftritt: • Die Methode [oder das Laufzeitsystem] erzeugt und wirft ein Ausnahme-Objekt, dasInformationen über den Fehlertyp und Status des Programms, als der Fehler passierte, usw. enthält • Die Ausnahme wird ausgelöst: die Kontrolle und das erzeugte Ausnahme-Objekt wird dem Laufzeitsystem übergeben. • Das Laufzeitsystem sucht Code für die Behandlung der Ausnahme. • Kandidaten dafür sind Methoden in der Aufrufkette der Methode, in der der Fehler auftrat. • Die Aufrufkette wird rückwärts durchsucht.

  22. Auslösen von Ausnahmen public class Car { public void start() { // . . . // battery might be empty // driver might not be authorized } } Die Batterien sind möglicherweise (fast) leer. Um einen Programmabsturz zu vermeiden, soll eine Ausnahmeausgelöst werdenBatteryLowException Möglicherweise liegt keine Berechtigung vor, das Auto zu fahren Ausnahme:SecurityException

  23. Auslösen von Ausnahmen public class Car { publicvoid start() { if (batteryLevel <= 5) thrownewBatteryLowException( "Battery is empty"); if (!driver.isAuthorized()) thrownewSecurityException( "No access rights"); // start the car } } Dieser Code wird vom Übersetzer so nicht akzeptiert! throw-Anweisung: "throw"Exception-Object. Nebenbedingung: Exception-Object muss vom Typ Exception abgeleitet sein (mehr gleich). Fast immer direkt durch new erzeugt.

  24. Deklaration eventuell ausgelöster Ausnahmen public class Car { publicvoid start() throwsBatteryLowException, SecurityException { // . . . // start car } } Die Operation muss in der Signatur deklarieren, dass sie potentiell Ausnahmen wirft! Potentiell ausgelöste Ausnahmen gehören zu der Signatur einer Methode genau so wie der Rückgabetyp. • Syntax der Deklaration: "throws" <Exception-List>. • <Exception-List> = <Exception-Name> • {"," <Exception-List>}. • Es können mehrere Ausnahmetypen deklariert werden • Java Compiler überprüft, ob die Deklaration korrekt ist • Können undeklarierte, unbehandelte Ausnahmen auftreten?

  25. Aufruf von Methoden, die Ausnahmen auslösen public class Bar { // ... publicvoiddoSmthWithCar(Car car) { // ... car.start(); // ... } } Dieser Code wird vom Übersetzer nicht akzeptiert! Grund: doSmthWithCar ruft eine Methode auf, welche Ausnahmen auslösen könnte. Diese werden aber ignoriert  Programmabsturz!

  26. Aufruf von Methoden, die Ausnahmen auslösen public class Bar { publicvoiddoSmthWithCar(Car car) { // ... try{ car.start(); } catch(BatteryLowExceptionble) { // Exception handling } catch(SecurityException se) { // Exception handling } // ... } } try-Block signalisiert die Bereitschaft, auftretende Ausnahmen abzufangen und zu behandeln Das Abfangen und die Behandlung von Ausnahmen erfolgt in catch-Blocks. 1. Möglichkeit: Die aufrufende Methode behandelt die von aufgerufenen Methoden erzeugten Ausnahmen

  27. Behandlung auftretender Ausnahmen • Jeder catch-Block deklariert einen formalen Parameter • Beispiel: catch(SecurityException se) • Der Parametertyp legt den Ausnahmetyp fest, welchen der catch-Block abfängt und behandelt • Hier: SecurityException • Der Parameter (hier: se) ist lokale Variable im catch-Block • Erlaubt Verweise auf das zu behandelte Ausnahme-Objekt • Erlaubt Zugriff auf Methoden oder Attribute der Ausnahme • Ausnahmen sind im Prinzip ganz normale Java Objekte, definiert in ganz normalen Java Klassen! • Typische Methodenaufrufe: • se.getMessage() – Zugriff auf Fehlermeldungstext • se.printStackTrace() – Aufrufreihenfolge ausgeben

  28. Behandlung mehrerer Ausnahmen eines Blocks Wie behandelt man mehrere mögliche Ausnahmen eines Befehls oder Befehlsblocks? • Es können mehrere catch-Blöcke zu einem try-Block angegeben werden! • Einzelne Befehle, die möglicherweise mehrere Ausnahmen auslösen können, werden auch in einem try-Block eingeschlossen. • Es wird dererste passende catch-Block ausgeführt • Vorsicht, wenn Ausnahmen in einer Vererbungsbeziehung stehen (mehr gleich)!

  29. Weiterreichen auftretender Ausnahmen public class Bar { public void doSmthWithCar(Car car) throwsBatteryLowException, SecurityException{ // ... car.start(); // ... } } 2. Möglichkeit: Die aufrufende Methode reicht alle oder einige der Ausnahmen entlang der Aufrufkette weiter.

  30. main start() o2.doSmthWithCar() Weiterreichen auftretender Ausnahmen public class Client { public static void main(String[] args) { // ... Car car = ...; Bar o2 = new Bar(); o2.doSmthWithCar(car); // ... } } :Client o2: Bar :Car Suche die erste Methode, die einen catch-Block für die ausgelöste Ausnahme hat, und fahre mit dem Code im catch-Block fort. Wird kein passender catch-Block gefunden, endet das Programm mit einer Fehlermeldung.

  31. Sicherstellung der Ausführung von Aktionen Wie kann sichergestellt werden, dass in jedem Fall bestimmte Aktionen ausgeführt wurden? • Problem: Bei Programmen mit Ausnahmebehandlung gibt es mehrere Möglichkeiten, das Programm zu verlassen. • Manchmal müssen bestimmte Aktionen garantiert werden, egal, ob nun eine Ausnahme aufgetreten ist oder nicht. • Beispiel: Schreiben in eine erfolgreich geöffnete Datei • Die Datei sollte in jedem Fall geschlossen werden – egal, ob Daten schreibbar waren oder nicht

  32. Der finally-Block Code-Duplikation public void test() { Switch sw = new Switch(); try { sw.on(); // code derevtl. Exceptions wirft sw.off(); } catch (BatteryLowException e) { sw.off(); // unnoetige Code-Duplikation System.err.println("Caught BatteryLowException"); } catch (SecurityException e) { sw.off(); // unnoetige Code-Duplikation System.err.println("Caught SecurityException"); } }

  33. Sicherstellung der Ausführung von Aktionen • Dazu bietet Java den finally-Block • Befehle des finally-Blocks werden immer ausgeführt: • Nach Ende des try-Blocks, falls keine Ausnahme auftrat • Nach Ende eines catch-Blocks, falls eine Ausnahme auftrat publicvoidtest() { Switch sw = newSwitch(); try { sw.on(); // codethatmaythrowexceptions } catch (BatteryLowExceptionblExc) { // ... } catch (SecurityExceptionsecEx) { // ... } finally { sw.off(); } } sw wird auf jeden Fall abgeschaltet, unabhängig vom Kontrollfluss des Programms

  34. Vorteile des finally-Blocks • Die Anweisungen des finally-Blocks werden unabhängig vom Auftreten einer Ausnahme ausgeführt • Keine Duplizierung von Code, der in jedem Fall – ob mit oder ohne Exception – auszuführen ist • Achtung: • Befehle im finally-Block können wiederum Ausnahmen auslösen! • Schließen von Dateien oder Netzwerkverbindungen, Null Pointer, ... • Behandlung im finally-Block wie in jedem anderen Block...

  35. Übersicht • Fehler und deren Klassifizierung • Fehlerbehandlung ohne eigenständige Sprachmechanismen und deren Probleme • Grundkonzepte der Fehlerbehandlung mit eigenständigen Sprachmechanismen am Beispiel von Java • Vorteile der Fehlerbehandlung mit eigenständigen Sprachmechanismen am Beispiel von Java • Zusammenfassung

  36. Vorteile der Fehlerbehandlung miteigenständigen Sprachmechanismen • Trennung der normalen Verarbeitung von der Fehlerbehandlung • Weitergabe von Fehlern entlang der dynamischen Aufrufkette • Unterscheidung und Gruppierung verschiedener Fehlertypen • Kontrolle durch den Compiler, dass bestimmte Fehlertypen auf jeden Fall behandelt werden

  37. 1. Trennung der Fehlerbehandlung • Javas Konstrukte für Ausnahmebehandlung ermöglichen die Trennungdesnormalen Programmcodes vonFehlerbehandlung • Achtung! Ausnahme-behandlung erspart keine Arbeit • Der Vorteil liegt in der Trennung. voidreadFile() { try { open thefile; determineitssize; allocatethatmuchmemory; readthefileintomemory; closethefile; } catch (fileOpenFailed) { doSomething; } catch (sizeDeterminationFailed) { doSomething; } catch (memoryAllocationFailed) { doSomething; } catch (readFailed) { doSomething; } catch (fileCloseFailed) { doSomething; } }

  38. 2. Fortpflanzung der Ausnahmen • Angenommen, readFile ist die vierte Methode in einer Kette von Methodenaufrufen: method1, method2, method3, readFile • Dabei ist method1 die einzige Methode, die daran interessiert ist, die Fehler von readFile zu behandeln. • In traditionellen Sprachen müssen method2 und method3 die Fehlerkodierungen weiterleiten, die von readFile zurückgegeben werden, bis sie method1 erreichen. method3 { callreadFile; } method1 { call method2; } method2 { call method3; }

  39. 2. Fortpflanzung der Ausnahmen method1{ errorCodeType error; error = call method2; if (error) doErrorProcessing; else proceed; } errorCodeType method2{ errorCodeType error; error = call method3; if (error) return error; else proceed; } errorCodeType method3{ errorCodeType error; error = call readFile; if (error) return error; else proceed; }

  40. 2. Fortpflanzung der Ausnahmen • Im Gegensatz dazu sucht das Laufzeitsystem von Java rückwärts in der Aufrufkette nach Methoden, die an der Behandlung der Fehler interessiert sind. method1 { try { callmethod2; } catch(exception) { doErrorProcessing; } } method2 throwsexception { call method3; } method3 throwsexception { callreadFile; }

  41. 3. Hierarchie der Java Ausnahmetypen • Alle Ausnahmetypen in Java erben von der vordefinierten Klasse java.lang.Throwable “schwerwiegende" VM Ausfälle sollen und können nicht von einem Programm abgefangen werden können ignoriert werden können vom Programmierer erweitert werden

  42. Die Klasse Throwable Throwable Erzeugt ein Throwable-Objekt mit einer spezifischen Fehlermeldung (error-message) Throwable() Throwable(String) getMessage() printStackTrace() printStackTrace(PrintStream) ... Gibt Fehlermeldung zurück Gibt die Aufrufkette beim Auslösen der Ausnahme aus

  43. Methoden der Klasse Exception public class ExceptionMethods { public static void main(String[] args) { try { thrownew Exception("Hierkommteine Exception"); } catch (Exception e) { System.out.println("Exception gefangen"); System.out.println("e.getMessage(): "+e.getMessage()); System.out.println("e.toString(): "+e.toString()); System.out.println("e.printStackTrace():"); e.printStackTrace(); } } }

  44. Schwerwiegende Fehler: Error • Es macht keinen Sinn, solche Fehler abzufangen und zu behandeln: Der Compiler erzwingt die Behandlung von diesen Fehlern nicht. • Führen zum Programmabsturz • Programm kann nicht fortgeführt werden, z.B. kein Speicher mehr vorhanden

  45. Ungeprüfte Ausnahmetypen:RuntimeException • RuntimeExceptions sind Fehler, die überall im Programm auftreten könnten, abhängig von Laufzeitbedingungen: • Aufrufen einer Methode auf einem null-Objekt, der Versuch außerhalb der Grenzen eines Array zu lesen / schreiben, usw. Diese Fehler können, müssen aber nicht abgefangen werden.

  46. Ungeprüfte Ausnahmetypen:RuntimeException • Das Erzwingen der Behandlung dieser Fehler würde das Programm unnötig unübersichtlich machen • Solche Fehler können potentiell überall auftreten … • Ein catch-Block für NullPointerException wäre für jeden Operationsaufruf notwendig • Auch wenn der Programmierer sicher ist, dass eine Variable an einer bestimmten Stelle des Programms ein gültiges Objekt enthält • Der Compiler kann das statisch nicht testen publicstaticvoidmain(String[] args) { // evtl. ArrayIndexOutOfBoundsExc., NumberFormatException Double doubleValue = Double.parseDouble(args[0]); // evtl. ArrayIndexOutOfBoundsExc., NumberFormatException Integer intValue = Integer.parseInt(args[1]) }

  47. Geprüfte Ausnahmetypen • Geprüfte Ausnahmetypen sind alle Ausnahmetypen, die von Exception aber nicht von RuntimeException erben • Mehrere vordefinierte Ausnahmeklassen: FileNotFoundException,IOException, etc. • Anwendungsspezifische Ausnahmen • können vom Programmierer als direkte oder indirekte Erben von Exceptiondefiniert werden.

  48. Geprüfte Ausnahmetypen • Der Compiler erzwingt die Behandlung von geprüften Ausnahmetypen • Eine Methode muss für geprüfte Ausnahmen • entweder eine Behandlung definieren (catch), oder • alle Ausnahmen dieser Typen, die innerhalb des Methodenbereiches vorkommen, weitergeben, indem sie in einem throws-Ausdruck deklariert werden. Der Bereich einer Methode M ist nicht nur der eigene Code, sondern auch der Code von Methoden, die von M aufgerufen werden.Diese Definition ist rekursiv.

  49. Gruppierung von Ausnahmetypen • Exceptions sind normale Java-Objekte mit Vererbungshierarchie • Daher kann man Spezialisierungen / Verallgemeinerungen definieren zwischen den Exception-Typen • Eine IndexOutOfBoundsExceptionwird geworfen, wenn ein Index außerhalb des gültigen Bereiches liegt • ArrayIndexOutOfBoundsException ist eine Unterklasse für Array-Zugriffe • “Außerhalb des Bereichs”: Indexwert ist negativ oder größer oder gleich der Array-Länge • Der Programmierer einer Methode kann mehr oder weniger spezifische Exceptions behandeln

  50. Gruppierung von Ausnahmetypen Die Fassung von op1behandelt verschiedene Exceptions verschieden. publicvoidop1() { // ... catch (ArayIndexOutOfBoundsExceptioninvInd) { // macht etwas mit invInd } catch (NullPointerExceptionnpe) { // macht etwas mit npe } catch (NoSuchElementExceptioneType) { // macht etwas mit eType } } public void op1() { // ... catch (RuntimeException e) { // macht etwas mit e } } Hier werden alle Exceptions gleich behandelt.

More Related