grundlagen der informatik i thema 16 ausnahmebehandlung n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Grundlagen der Informatik I Thema 16: Ausnahmebehandlung PowerPoint Presentation
Download Presentation
Grundlagen der Informatik I Thema 16: Ausnahmebehandlung

Loading in 2 Seconds...

play fullscreen
1 / 63

Grundlagen der Informatik I Thema 16: Ausnahmebehandlung - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Grundlagen der Informatik I Thema 16: Ausnahmebehandlung' - macon


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
grundlagen der informatik i thema 16 ausnahmebehandlung

Grundlagen der Informatik IThema 16: Ausnahmebehandlung

Prof. Dr. Max Mühlhäuser

Dr. Guido Rößling

bersicht
Ü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
klassifikation von fehlern
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

klassifikation von fehlern1
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
fehlerbehandlung
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
fehlerbehandlung bug debugging
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
schwerwiegende laufzeitfehler error
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
leichtgewichtige fehler
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

einige typische ausnahmen
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!
einige typische ausnahmen1
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)
einige typische ausnahmen2
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

fehlerbehandlung1
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
bersicht1
Ü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
fehlerbehandlung ohne sprachmechanismen
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
fehlerbehandlung ohne sprachmechanismen1
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;

}

fehlerbehandlung ohne sprachmechanismen2
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.
fehlerbehandlung ohne sprachmechanismen3
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;

}

fehlerbehandlung ohne sprachmechanismen4
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!
fehlerbehandlung ohne sprachmechanismen5
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!
bersicht2
Ü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
ausnahmebehandlung in java
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.
ausl sen von ausnahmen
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

ausl sen von ausnahmen1
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.

deklaration eventuell ausgel ster ausnahmen
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?
aufruf von methoden die ausnahmen ausl sen
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!

aufruf von methoden die ausnahmen ausl sen1
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

behandlung auftretender ausnahmen
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
behandlung mehrerer ausnahmen eines blocks
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)!
weiterreichen auftretender ausnahmen
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.

weiterreichen auftretender ausnahmen1

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.

sicherstellung der ausf hrung von aktionen
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
der finally block
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");

}

}

sicherstellung der ausf hrung von aktionen1
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

vorteile des finally blocks
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...
bersicht3
Ü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
vorteile der fehlerbehandlung mit eigenst ndigen sprachmechanismen
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
1 trennung der fehlerbehandlung
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;

}

}

2 fortpflanzung der ausnahmen
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;

}

2 fortpflanzung der ausnahmen1
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;

}

2 fortpflanzung der ausnahmen2
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;

}

3 hierarchie der java ausnahmetypen
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

die klasse throwable
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

methoden der klasse exception
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();

}

}

}

schwerwiegende fehler error
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
ungepr fte ausnahmetypen runtimeexception
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.

ungepr fte ausnahmetypen runtimeexception1
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])

}

gepr fte ausnahmetypen
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.
gepr fte ausnahmetypen1
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.

gruppierung von ausnahmetypen
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
gruppierung von ausnahmetypen1
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.

gruppierung von ausnahmetypen2
Gruppierung von Ausnahmetypen

public void op1() {

// ...

catch (RuntimeException e) {

// machtetwasmit 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 alleExceptions gleich behandeln.

NICHT EMPFOHLEN!

public void op1() {

// ...

catch (Exception e) {

// machtetwasmit e

}

}

gruppierung von ausnahmetypen3
Gruppierung von Ausnahmetypen

publicvoidop1() {

// ...

catch (ArrayIndexOutOfBoundsExceptioninvInd) {

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

publicvoidop1() {

// ...

catch (RuntimeException e) {

// macht etwas mit e

}

catch (ArrayIndexOutOfBoundsExceptioninvInd) {

// macht etwas mit invInd

}

}

Was passiert bei der Auslösung einer ArrayIndexOutOfBoundsException?

vererbung von ausnahmen
„Vererbung“ von Ausnahmen

public class CarExceptionextendsException {}

publicclassNoGasolineextendsCarException {}

publicclassNoSpecialGasolineextendsNoGasoline {}

publicclassBadWeatherextendsException {}

publicclassCar {

publicvoidstart() throwsNoGasoline { … }

publicvoidstop() throwsCarException { … }

}

publicclassSportsCarextendsCar {

publicvoidstart() throwsNoSpecialGasoline { … }

publicvoidstop() throwsBadWeather { … }

publicstaticvoid main(String[] args) {

try{

newSportsCar().start();

} catch(NoSpecialGasoline e) { }

}

}

Dieser Code wird vom Übersetzer

so nicht akzeptiert!

vererbung von ausnahmen1
„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.
konstruktoren und ausnahmen
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.

publicclassCar {public Car() throwsNoGasoline {}}

publicclass SportsCar extends Car {

public SportsCar throwsNoGasoline {

super(); //wirft vielleicht eine NoGasoline Ausnahme

//...

}

}

NoGasoline kann nicht mit NoSpecialGasoline ersetzt werden

bedeutung von namen
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.
weiterleiten von exceptions
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.

catch (Exception e) {

System.out.println("An exception was thrown: "+e);

throw e;

// throwe.fillInStackTrace();

}

pr fen auf erwartete ausnahmen in junit 4
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 erwarteteException 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)

publicvoiddivideByZero() {

calculator.divide(0);

}

bersicht4
Ü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
zusammenfassung
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…catchder Methode
    • Laufzeit-Ausnahmen können ignoriert, dürfen aber natürlich auch behandelt werden!
zusammenfassung1
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
zusammenfassung kontrollfluss im fehlerfall
Zusammenfassung: Kontrollfluss im Fehlerfall

Wie sieht der Kontrollfluss im Fehlerfall aus?

  • 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()“
  • 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
ablauf ausnahmebehandlung

Ausnahme des Typs TE wird

in einem try-Block ausgelöst

Ablauf: Ausnahmebehandlung

Verlassen des try-Blocks

Durchsuchen der catch-Klauseln

(catch-Typ=TE oder catch-Typ

ist Oberklasse von TE) gefunden?

nein

ja

Ausführung der Anweisungen

des ersten solchen catch-Blocks

Ausführung der Anweisungen

des (optionalen) finally-Blocks

Ausführung der Anweisungen

des (optionalen) finally-Blocks

catch-Block durchlaufen, ohneneue Ausnahme auszulösen?

Weitergabe des neuen

Ausnahmeobjekts an den

umliegenden try-Blocks

nein

ja

Fortsetzung hinter try-Block