Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only...

Telecooperation/RBG

Technische Universität Darmstadt

Copyrighted material; for TUD student use only

Grundlagen der Informatik IThema 16: Ausnahmebehandlung

Prof. Dr. Max MühlhäuserDr. Guido Rößling

Dr. G. RößlingProf. Dr. M. Mühlhäuser

RBG / Telekooperation©

Grundlagen der Informatik I: T16

Ü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

2




• Lexikalische Fehler: Falsche oder unbekannte Worte

// ...int[] result = neu int[5];result.size();// ...

• Syntaxfehler: Falsche Anordnung von Worten //...move(); public static void main(String[] args) { // ...}//...

Klassifikation von Fehlern

3

Lexikalische und syntaktische Fehler

werden vom Compiler entdeckt und signalisiert




Klassifikation von Fehlern

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




Fehlerbehandlung

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 robust genannt.




Fehlerbehandlung, Bug, Debugging

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




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

7




Leichtgewichtige Fehler• Ausnahme (Exception) können innerhalb des

Programms abgefangen werden; Programmfortsetzung ist möglich.

Problem: Eingabe eines fehlerhaften Dateinamens durch BenutzerBehebung: Neueingabe verlangen

Problem: Fehlerhafte Daten in einer Datei, die ignoriert

werden können, z.B. nicht interpretierbare Bild- oder AudiosignaleBehebung: Ignorieren

Problem: Zusammenbruch einer Netzverbindung Behebung: Neuaufbau der Verbindung 8




Einige typische Ausnahmen

9

• 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!

public void printPerson() { Person aPerson = null; // ... printName(aPerson); // ...}public void printName(Person p) { System.out.println(p.name);}




Einige typische Ausnahmen

10

int[] matrikelNummern = new int[27];

for (int i = 0; i <= 27; i++) System.out.println(matrikelNummern[i]);

• 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)




Einige typische Ausnahmenpublic static void main(String[] args) { int count; count = Integer.parseInt(args[1]); // ...}

11

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

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

Dieser Zugriff führt potentiell zu mehreren Fehlern!




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

12




Übersicht





• Zusammenfassung

13




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 14





• 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.

15

readFile { open the file; determine its size; allocate that much memory; read the file into memory; close the file;}





• 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.

16





17

errorCodeType readFile { initialize errorCode = 0; open the file; if (theFileIsOpen) { determine the length of the file; if (gotTheFileLength) { allocate that much memory; if (gotEnoughMemory) { read the file into memory; if (readFailed) { errorCode = -1; } } else { errorCode = -2; } } else { errorCode = -3; } close the file; if (theFileDidntClose && errorCode == 0) { errorCode = -4; } else { errorCode = errorCode && -4; } } else { errorCode = -5; } return errorCode;}





• 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!

18





• 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

19

Eine Ausnahmebehandlung ohne eigenständige Sprachkonstrukte hat sich nicht bewährt!Eine Ausnahmebehandlung ohne eigenständige Sprachkonstrukte hat sich nicht bewährt!




Übersicht





• Zusammenfassung

20




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, das Informationen ü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.

21




Auslösen von Ausnahmen

22

Die Batterien sind möglicherweise (fast) leer. Um einen Programmabsturz zu vermeiden, soll eine Ausnahme ausgelöstwerden BatteryLowException

Möglicherweise liegt keine Berechtigung vor, das Auto zu fahren Ausnahme: SecurityException

public class Car {

public void start() { // . . . // battery might be empty // driver might not be authorized }}




public class Car { public void start() {

if (batteryLevel <= 5) throw new BatteryLowException( "Battery is empty");

if (!driver.isAuthorized()) throw new SecurityException( "No access rights"); // start the car }}

Auslösen von Ausnahmen

23

throw-Anweisung: "throw" Exception-Object.Nebenbedingung: Exception-Object muss vom Typ Exception abgeleitet sein (mehr gleich).Fast immer direkt durch new erzeugt.

Dieser Code wird

vom Übersetzer so nicht

akzeptiert!




Deklaration eventuell ausgelöster Ausnahmen

24

public class Car { public void start() throws BatteryLowException, 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?




Aufruf von Methoden, die Ausnahmen auslösen

25

// ... car.start(); // ... }}

public class Bar { // ...

public void doSmthWithCar(Car car) {

Dieser Code wird vom Übersetzer

nicht akzeptiert!

Grund: doSmthWithCar ruft eine Methode auf, welche Ausnahmen auslösen könnte.

Diese werden aber ignoriert Programmabsturz!




Aufruf von Methoden, die Ausnahmen auslösen

26

public class Bar { public void doSmthWithCar(Car car) { // ... try { car.start(); } catch (BatteryLowException ble) { // Exception handling } catch (SecurityException se) { // Exception handling } // ... }}

1. Möglichkeit:Die aufrufende Methode behandelt die von aufgerufenen Methoden erzeugten Ausnahmen

try-Block signalisiert die Bereitschaft, auftretende Ausnahmen abzufangen und

zu behandeln

Das Abfangen und die Behandlung von Ausnahmen erfolgt in catch-Blocks.




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

27




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 der erste passende catch-Block ausgeführt– Vorsicht, wenn Ausnahmen in einer Vererbungsbeziehung

stehen (mehr gleich)!

28




Weiterreichen auftretender Ausnahmen

29

2. Möglichkeit:Die aufrufende Methode reicht alle oder einige der Ausnahmen entlang der Aufrufkette weiter.

2. Möglichkeit:Die aufrufende Methode reicht alle oder einige der Ausnahmen entlang der Aufrufkette weiter.

public class Bar { public void doSmthWithCar(Car car) throws BatteryLowException, SecurityException { // ... car.start(); // ... } }




public class Client { public static void main(String[] args) { // ... Car car = ...; Bar o2 = new Bar(); o2.doSmthWithCar(car); // ... }}

Weiterreichen auftretender Ausnahmen

30

o2: Bar :Car

o2.doSmthWithCar()

main

start()

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 Programmmit einer Fehlermeldung.

:Client




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

31




Der finally-Block

32

public void test() { Switch sw = new Switch(); try { sw.on(); // code der evtl. 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"); }}

Code-Duplikation




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

33

public void test() { Switch sw = new Switch(); try { sw.on(); // code that may throw exceptions } catch (BatteryLowException blExc) { // ... } catch (SecurityException secEx) { // ... } finally { sw.off(); }}

sw wird auf jeden Fall abgeschaltet, unabhängig vom Kontrollfluss des Programms




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...

34




Übersicht





• Zusammenfassung

35




Vorteile der Fehlerbehandlung miteigenständigen Sprachmechanismen

1. Trennung der normalen Verarbeitung von der Fehlerbehandlung

2. Weitergabe von Fehlern entlang der dynamischen Aufrufkette

3. Unterscheidung und Gruppierung verschiedener Fehlertypen

4. Kontrolle durch den Compiler, dass bestimmte Fehlertypen auf jeden Fall behandelt werden

36




1. Trennung der Fehlerbehandlung

• Javas Konstrukte für Ausnahmebehandlung ermöglichen die Trennung des normalen Programmcodes von Fehlerbehandlung

• Achtung! Ausnahme-behandlung erspart keine Arbeit – Der Vorteil liegt in

der Trennung.

37

void readFile() { try { open the file; determine its size; allocate that much memory; read the file into memory; close the file; } catch (fileOpenFailed) { doSomething; } catch (sizeDeterminationFailed) { doSomething; } catch (memoryAllocationFailed) { doSomething; } catch (readFailed) { doSomething; } catch (fileCloseFailed) { doSomething; }}




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.

38

method1 { call method2;}

method2 { call method3;}

method3 { call readFile;}





39

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;}





• Im Gegensatz dazu sucht das Laufzeitsystem von Java rückwärts in der Aufrufkette nach Methoden, die an der Behandlung der Fehler interessiert sind.

40

method1 { try { call method2; } catch (exception) { doErrorProcessing; }}

method2 throws exception { call method3;}

method3 throws exception { call readFile;}




3. Hierarchie der Java Ausnahmetypen• Alle Ausnahmetypen in Java erben von der

vordefinierten Klasse java.lang.Throwable

41

“schwerwiegende" VM Ausfälle sollen und können nicht von einem

Programm abgefangen werden

können ignoriert werden

können vom Programmierer erweitert

werden




Die Klasse Throwable

42

Throwable()

Throwable(String)

getMessage()

printStackTrace()

printStackTrace(PrintStream)

...

Throwable Erzeugt ein Throwable-Objekt mit einer spezifischen Fehlermeldung (error-message)

Gibt Fehlermeldung zurück

Gibt die Aufrufkette beim Auslösen der Ausnahme aus




Methoden der Klasse Exception

43

public class ExceptionMethods { public static void main(String[] args) { try { throw new Exception("Hier kommt eine 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(); } }}




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

44

• Programm kann nicht fortgeführt werden, z.B. kein Speicher mehr vorhanden




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.

45

Diese Fehler können, müssen aber nicht abgefangen werden.




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

46

public static void main(String[] args) { // evtl. ArrayIndexOutOfBoundsExc., NumberFormatException Double doubleValue = Double.parseDouble(args[0]); // evtl. ArrayIndexOutOfBoundsExc., NumberFormatException Integer intValue = Integer.parseInt(args[1])}




Geprüfte Ausnahmetypen• Geprüfte Ausnahmetypen sind alle Ausnahmetypen, die

von Exception aber nicht von RuntimeException erben• Mehrere vordefinierte Ausnahmeklassen:

FileNotFoundException,IOException, etc.

47

Anwendungsspezifische Ausnahmen

können vom Programmierer als direkte oder indirekte Erben von Exception definiert werden.




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.

48

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.




Gruppierung von Ausnahmetypen

• Exceptions sind normale Java-Objekte mit Vererbungshierarchie

• Daher kann man Spezialisierungen / Verallgemeinerungen definieren zwischen den Exception-Typen

• Eine IndexOutOfBoundsException wird 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

49





50

public void op1() { // ... catch (ArayIndexOutOfBoundsException invInd) { // macht etwas mit invInd } catch (NullPointerException npe) { // macht etwas mit npe } catch (NoSuchElementException eType) { // macht etwas mit eType }}

Die Fassung von op1 behandelt verschiedene Exceptions verschieden.

public void op1() { // ... catch (RuntimeException e) { // macht etwas mit e }}

Hier werden alle Exceptions gleich behandelt.





51

public void op1() { // ... catch (RuntimeException e) { // macht etwas mit e }}

public void op1() { // ... catch (Exception e) { // macht etwas mit e }}

Man könnte auch mit Fallunterscheidungen die verschiedenen Subtypen von RuntimeException unterscheiden. Die Fassung der vorherigen Folie ist:

• besser dokumentiert• einfacher zu warten

Man kann sogar alle Exceptions gleich behandeln.NICHT EMPFOHLEN!





52

public void op1() { // ... catch (RuntimeException e) { // macht etwas mit e } catch (ArrayIndexOutOfBoundsException invInd) { // macht etwas mit invInd }}

public void op1() { // ... catch (ArrayIndexOutOfBoundsException invInd) { // macht etwas mit invInd } catch (RuntimeException e) { // macht etwas mit e } }

Laufzeitsystem wählt den ersten catch-Block, der den Typ der ausgelösten Ausnahme oder einen Supertyp davon behandelt.

Was passiert bei der Auslösung einer ArrayIndexOutOfBoundsException?




„Vererbung“ von Ausnahmenpublic class CarException extends Exception {}public class NoGasoline extends CarException {}public class NoSpecialGasoline extends NoGasoline {}public class BadWeather extends Exception {}

public class Car { public void start() throws NoGasoline { … } public void stop() throws CarException { … }}

public class SportsCar extends Car { public void start() throws NoSpecialGasoline { … } public void stop() throws BadWeather { … } public static void main(String[] args) { try { new SportsCar().start(); } catch (NoSpecialGasoline e) { } }}

53

Dieser Code wird

vom Übersetzer so nicht

akzeptiert!




„Vererbung“ von Ausnahmen

• Regel 1:– Eine überschreibende Methode darf alle

Ausnahmen, die von der überschriebenen Methode deklariert werden, oder davon abgeleitete werfen.

• Regel 2:– Methoden von abgeleiteten Klassen dürfen

keine Ausnahmen werfen, die nicht vom gleichen Typ oder von einem Subtyp einer Ausnahme sind, die in der Methodensignatur der Basisklasse deklariert ist.

54




Konstruktoren und Ausnahmen

• Vor Aufruf des Konstruktors der Basisklasse darf nichts stehen, nicht einmal ein try Block.

• Ausnahmen des Basisklassen-Konstruktors müssen im Konstruktor der abgeleiteten Klasse wieder aufgelistet werden.

55

public class Car { public Car() throws NoGasoline {}}

public class SportsCar extends Car {

public SportsCar throws NoGasoline {

super(); //wirft vielleicht eine NoGasoline Ausnahme

//...

}

}

NoGasoline kann nicht mit NoSpecialGasoline ersetzt werden




Bedeutung von Namen

• Der Name einer Ausnahme ist typischerweise das wichtigste.

• In der Regel wählt man lange, aussagekräftige Namen.

• Der Code der Ausnahmeklasse selbst ist meistens minimal.

• Nachdem man eine Ausnahme gefangen hat, benötigt man sie in der Regel nicht mehr.

56




Weiterleiten von Exceptions

• So viel wie möglich direkt erledigen und dann eine globalen Stelle den Rest erledigen lassen

• fillInStackTrace speichert im Throwable Objekt Informationen über den aktuellen Zustand des Aufruf-Stacks ab.

57

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




Prüfen auf erwartete Ausnahmen in JUnit 4

• Erinnern Sie sich an den Taschenrechner mit JUnit in T12?– Dort gab es eine Testmethode „divideByZero()“– Diese wirft bei Aufruf eine ArithmeticException

• Wir wollen testen, ob diese erwartete Exception auftritt– Wenn ja, ist das korrekt (erwartete Exception eingetreten)– Wenn nein, ist das ein Fehler

• Wie können wir die Exception über JUnit „abfangen“?• Wir nutzen einen Parameter für die @Test-Annotation

– @Test(expected=ExceptionType.class)• Im Beispiel also:@Test(expected = ArithmeticException.class)

public void divideByZero() { calculator.divide(0); }

58




Übersicht





• Zusammenfassung

59




Zusammenfassung• Jedes Programm kann prinzipiell Fehler enthalten• Java unterstützt die Fehlerbehandlung

– Errors sind schwerwiegende Fehler nicht behebbar– Ausnahmen sind Fehler, die behoben werden können

• Im wesentlichen drei Vorgehensweisen:– Deklarieren und Weiterreichen der Ausnahme erfolgt

durch „throws“ und Ausnahmetyp im Methodenkopf– Behandeln der Ausnahme(n) in try…catch der Methode– Laufzeit-Ausnahmen können ignoriert, dürfen aber

natürlich auch behandelt werden!

60




Zusammenfassung

• Die Exception-Behandlung erfolgt in try...catch– Ausnahmen auslösende Befehle (meist Methodenaufrufe)

stehen in einem try-Block– Mögliche Ausnahmen werden in catch-Blöcken

behandelt– Jeder catch-Block behandelt einen Ausnahmetyp– Dazu wird ein Parameter vom Ausnahmetyp deklariert

• Die Suche nach dem „passenden“ catch erfolgt von oben nach unten– Der erste „passende“ catch-Block wird genutzt– Bei der Anordnung ist die Vererbungshierarchie

beachten!

• Befehle im finally-Block werden stets ausgeführt– Egal, ob eine Ausnahme auftrat oder nicht– Ideal, um „sauberzumachen“, etwa Dateien zu schließen

61




Zusammenfassung: Kontrollfluss im Fehlerfall

Wie sieht der Kontrollfluss im Fehlerfall aus?

1. Erzeugung eines „passenden“ Ausnahme-Objekts• Das Ausnahme-Objekt beschreibt Problem und ggf. Ursache

• Aktuelle Klasse (Name!), evtl. Codezeile, Fehlerbeschreibung (Text)

• Die Anlegung des Ausnahme-Objekts kann erfolgen...• „automatisch“ durch das Laufzeitsystem (z.B.

NullPointerException)• durch Methodenaufrufe ausgelöst (z.B.

FileNotFoundException)• durch den Programmierer mittels „throw new XXX()“

2. Die Laufzeitumgebung sucht nach passendem catch• Zunächst im aktuellen Block bis hin zur aktuellen Methode• Dann in der Methode, die diese Methode aufrief…• ...und so weiter in der Aufrufkette, ggf. bis zum Start des

Programms

62




Ablauf: Ausnahmebehandlung

63

Ausnahme des Typs TE wird in einem try-Block ausgelöst

Verlassen des try-Blocks

Durchsuchen der catch-Klauseln

Ausführung der Anweisungen des ersten solchen catch-Blocks

Ausführung der Anweisungen des (optionalen) finally-Blocks

Fortsetzung hinter try-Block

Weitergabe des neuenAusnahmeobjekts an den umliegenden try-Blocks

ja

ja

nein

nein

(catch-Typ=TE oder catch-Typ ist Oberklasse von TE) gefunden?

catch-Block durchlaufen, ohneneue Ausnahme auszulösen?

Ausführung der Anweisungen des (optionalen) finally-Blocks

Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only...

Documents

Transcript of Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only...