Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil8 Ausnahmen müssen sein
Pfeil8.1 Problembereiche einzäunen
Pfeil8.1.1 Exceptions in Java mit try und catch
Pfeil8.1.2 Geprüfte und ungeprüfte Ausnahmen
Pfeil8.2 Geprüfte Ausnahmen
Pfeil8.2.1 Letzte ausgeführte Java-Programme loggen
Pfeil8.2.2 try-catch-Behandlung
Pfeil8.2.3 throws im Methodenkopf angeben
Pfeil8.3 Ungeprüfte Ausnahmen (RuntimeException)
Pfeil8.3.1 Eine NumberFormatException fliegt
Pfeil8.3.2 Bekannte RuntimeException-Klassen
Pfeil8.3.3 Kann man abfangen, muss man aber nicht
Pfeil8.4 Gut gefangen
Pfeil8.4.1 Bitte nicht schlucken – leere catch-Blöcke
Pfeil8.4.2 Wiederholung abgebrochener Bereiche *
Pfeil8.4.3 Mehrere Ausnahmen auffangen
Pfeil8.4.4 Ablauf einer Ausnahmesituation
Pfeil8.4.5 Abschlussbehandlung mit finally
Pfeil8.5 Die Klassenhierarchie der Ausnahmen
Pfeil8.5.1 Eigenschaften des Exception-Objekts
Pfeil8.5.2 Basistyp Throwable
Pfeil8.5.3 Die Exception-Hierarchie
Pfeil8.5.4 Oberausnahmen auffangen
Pfeil8.5.5 Schon gefangen?
Pfeil8.5.6 Alles geht als Exception durch
Pfeil8.5.7 Zusammenfassen gleicher catch-Blöcke mit dem multi-catch
Pfeil8.6 Auslösen eigener Exceptions
Pfeil8.6.1 Mit throw Ausnahmen auslösen
Pfeil8.6.2 Vorhandene Runtime-Ausnahmetypen kennen und nutzen
Pfeil8.6.3 Parameter testen und gute Fehlermeldungen
Pfeil8.6.4 Neue Exception-Klassen deklarieren
Pfeil8.6.5 Eigene Ausnahmen als Unterklassen von Exception oder RuntimeException?
Pfeil8.6.6 Ausnahmen abfangen und weiterleiten *
Pfeil8.6.7 Aufruf-Stack von Ausnahmen verändern *
Pfeil8.6.8 Präzises rethrow *
Pfeil8.6.9 Geschachtelte Ausnahmen *
Pfeil8.7 Automatisches Ressourcen-Management (try mit Ressourcen)
Pfeil8.7.1 try mit Ressourcen
Pfeil8.7.2 Die Schnittstelle AutoCloseable
Pfeil8.7.3 Mehrere Ressourcen nutzen
Pfeil8.7.4 try mit Ressourcen auf null-Ressourcen
Pfeil8.7.5 Ausnahmen vom close()
Pfeil8.7.6 Unterdrückte Ausnahmen *
Pfeil8.8 Besonderheiten bei der Ausnahmebehandlung *
Pfeil8.8.1 Rückgabewerte bei ausgelösten Ausnahmen
Pfeil8.8.2 Ausnahmen und Rückgaben verschwinden – das Duo return und finally
Pfeil8.8.3 throws bei überschriebenen Methoden
Pfeil8.8.4 Nicht erreichbare catch-Klauseln
Pfeil8.9 Harte Fehler – Error *
Pfeil8.10 Assertions *
Pfeil8.10.1 Assertions in eigenen Programmen nutzen
Pfeil8.10.2 Assertions aktivieren und Laufzeit-Errors
Pfeil8.10.3 Assertions feiner aktivieren oder deaktivieren
Pfeil8.11 Zum Weiterlesen
 

Zum Seitenanfang

8.4    Gut gefangen Zur vorigen ÜberschriftZur nächsten Überschrift

 

Zum Seitenanfang

8.4.1    Bitte nicht schlucken – leere catch-Blöcke Zur vorigen ÜberschriftZur nächsten Überschrift

Java schreibt vor, dass Ausnahmen in einem catch behandelt (oder nach oben geleitet) werden, aber nicht, was in catch-Blöcken zu geschehen hat. Sie können eine sinnvolle Behandlung beinhalten oder auch einfach leer sein. Ein leerer catch-Block ist in der Regel wenig sinnvoll, weil dann die Ausnahme klammheimlich unterdrückt wird. (Das wäre genauso wie ignorierte Statusrückgabewerte von C-Funktionen.)

Das Mindeste ist eine minimale Fehlerausgabe via System.err.println(e) oder das informativere e.printStackTrace(…) für eine Exception e oder das Loggen dieser Ausnahme. Noch besser ist das aktive Reagieren, denn die Ausgabe selbst behandelt diese Ausnahme nicht! Im catch-Block ist es durchaus legitim, wiederum andere Ausnahmen auszulösen und somit die Ausnahme umzuformen und nach oben weiterzureichen.

[»]  Hinweis *

Wenn wie bei einem Thread.sleep(…) die InterruptedException wirklich egal ist, kann natürlich auch der Block leer sein, doch gibt es dafür nicht so viele sinnvolle Beispiele.

 

Zum Seitenanfang

8.4.2    Wiederholung abgebrochener Bereiche * Zur vorigen ÜberschriftZur nächsten Überschrift

Es gibt in Java bei Ausnahmen bisher keine von der Sprache unterstützte Möglichkeit, an den Punkt zurückzukehren, der die Ausnahme ausgelöst hat. Das ist aber oft erwünscht, etwa dann, wenn eine fehlerhafte Eingabe zu wiederholen ist.

Wir werden mit JOptionPane.showInputDialog(…) nach einem String fragen und versuchen, diesen in eine Zahl zu konvertieren. Dabei kann natürlich etwas schiefgehen. Wenn ein Benutzer eine Zeichenkette eingibt, die keine Zahl repräsentiert, löst parseInt(…) eine NumberFormatException aus. Wir wollen in diesem Fall die Eingabe wiederholen:

Listing 8.5    src/main/java/com/tutego/insel/exception/ContinueInput.java, main()

int number = 0;

while ( true ) {

try {

String s = javax.swing.JOptionPane.showInputDialog(

"Bitte Zahl eingeben" );

number = Integer.parseInt( s );

break;

}

catch ( NumberFormatException ó_ò ) {

System.err.println( "Das war keine Zahl!" );

}

}

System.out.println( "Danke für die Zahl " + number );

System.exit( 0 ); // Beendet die Anwendung

Die gewählte Lösung ist einfach: Wir programmieren den gesamten Teil in einer Endlosschleife. Geht die problematische Stelle ohne Ausnahme durch, so beenden wir die Schleife mit break. Kommt es zu einer NumberFormatException, dann wird break nicht ausgeführt, und der Programmfluss führt wieder in die Endlosschleife.

 

Zum Seitenanfang

8.4.3    Mehrere Ausnahmen auffangen Zur vorigen ÜberschriftZur nächsten Überschrift

Wir wollen mithilfe der Klasse Scanner eine Webseite zeilenweise auslesen und alle dort enthaltenen E-Mail-Adressen sammeln. Dazu greifen wir zu zwei Klassen, die uns beim Einlesen der Zeilen helfen: URL und Scanner (siehe dazu Abschnitt 5.10.2, »Yes we can, yes we scan – die Klasse Scanner«). Zunächst repräsentiert die Klasse URL eine URL, also eine Internetadresse. Das URL-Objekt fragen wir mit openStream() nach einem Datenstrom, und diesen Datenstrom setzen wir in den Konstruktor der Scanner-Klasse. Mit dem Scanner können wir dann zeilenweise durch die Seite laufen und alles einsammeln, was wie eine E-Mail-Adresse aussieht.

Ausnahmen können von allen Codeblöcken ausgelöst werden, in Methoden genauso wie in Konstruktoren. Integer.parseInt(String) ist zum Beispiel eine Methode, die eine Ausnahme auslöst, wenn der String keine Zahl ist, und das wird in der API-Dokumentation erklärt. Genauso kündigt die API-Dokumentation des Konstruktors der Klasse URL an, dass eine Ausnahme ausgelöst wird, wenn die URL falsch formuliert wird (etwa als "telefon://0123123123"). Die Methode löst eine IOException aus, wenn es keinen Zugriff auf die Webseite gibt. Ausnahmen von Konstruktoren sind ein wichtiges Werkzeug, da sie effektiv verhindern, dass ein Objekt in einen falschen Startzustand kommt. Nicht nur der Konstruktor von URL löst im Fehlerfall eine IOException aus, sondern auch die URL-Methode openStream() (siehe Abbildung 8.4).

Die API-Dokumentation zeigt die Ausnahmen.

Abbildung 8.4    Die API-Dokumentation zeigt die Ausnahmen.

Beide Ausnahmen sind geprüfte Ausnahmen, da sie explizit vom Entwickler behandelt werden müssen. Damit zwingen uns der Konstruktor new URL(…) und die Methode openStream() eine Behandlung auf, ohne die wir sie nicht nutzen könnten. Dabei spielt es keine Rolle, ob die Ausnahmen vielleicht nie auftreten können – sie müssen behandelt werden (siehe Abbildung 8.5 und Abbildung 8.6).

Eine nicht behandelte Ausnahme wird als Fehler angezeigt.

Abbildung 8.5    Eine nicht behandelte Ausnahme wird als Fehler angezeigt.

IntelliJ zeigt Fehler an, und mit der Tastenkombination (Alt)+(¢) können sie direkt behoben werden.

Abbildung 8.6    IntelliJ zeigt Fehler an, und mit der Tastenkombination (Alt)+(¢) können sie direkt behoben werden.

Wir müssen uns diesen potenziellen Ausnahmen also stellen und daher die Problemzonen in einen try-Block schreiben:

Listing 8.6    src/main/java/com/tutego/insel/exception/FindAllEmailAddresses.java

import java.io.IOException;

import java.net.MalformedURLException;

import java.net.URL;

import java.util.Scanner;

import java.util.regex.Pattern;



public class FindAllEmailAddresses {



public static void main( String[] args ) {

printAllEMailAddresses( "https://www.rheinwerk-verlag.de/hilfe/service- inline image

und-kontakt_8" );

}



static void printAllEMailAddresses( String urlString ) {

try {

URL url = new URL( urlString );

Scanner scanner = new Scanner( url.openStream() );

Pattern pattern = Pattern.compile( "[\\w|-]+@\\w[\\w|-]*\\.[a-z]{2,3}" );

for ( String email; (email = scanner.findWithinHorizon( pattern, 0 )) != null; )

System.out.println( email );

}

catch ( MalformedURLException e ) {

System.err.println( "URL ist falsch aufgebaut!" );

}

catch ( IOException e ) {

System.err.println( "URL konnte nicht geöffnet werden!" );

}

}

}

Tritt beim Erzeugen des URL-Objekts oder bei der Verbindung eine Ausnahme auf, fängt der try-Block diese ab, und der catch-Teil bearbeitet sie. Einem try-Block können mehrere catch-Klauseln zugeordnet sein, die verschiedene Typen von Ausnahmen auffangen. Dass die Ressource Scanner am Ende nicht geschlossen wird, ist in dem Beispiel in Ordnung, weil das Programm direkt beendet wird und so alle Ressourcen freigegeben werden.

[»]  Hinweis

Zwar ist die MalformedURLException eine IOException, sodass wir hier nur IOException hätten angeben müssen, doch grundsätzlich lassen sich beliebig viele Ausnahmen, getrennt durch Kommata, aufzählen. Zu den Vererbungsbeziehungen und den Konsequenzen folgt in Abschnitt 8.5, »Die Klassenhierarchie der Ausnahmen«, später mehr.

Einen try-catch-Block kann Eclipse mit der Tastenkombination (Strg)+(1) selbst anlegen. Auch bietet Eclipse an, die Ausnahme an den Aufrufer weiterzuleiten.

Abbildung 8.7    Einen try-catch-Block kann Eclipse mit der Tastenkombination (Strg)+(1) selbst anlegen. Auch bietet Eclipse an, die Ausnahme an den Aufrufer weiterzuleiten.

 

Zum Seitenanfang

8.4.4    Ablauf einer Ausnahmesituation Zur vorigen ÜberschriftZur nächsten Überschrift

Das Laufzeitsystem erzeugt ein Ausnahmeobjekt, wenn ein Fehler über eine Exception angezeigt werden soll. Dann wird die Abarbeitung der Programmzeilen sofort unterbrochen, und das Laufzeitsystem steuert selbstständig die erste catch-Klausel an (oder springt weiter zum Aufrufer, wie wir gleich sehen werden). Wenn die erste catch-Klausel nicht zur Art der aufgetretenen Ausnahme passt, werden der Reihe nach alle übrigen catch-Klauseln untersucht, und die erste übereinstimmende Klausel wird angesprungen (oder ausgewählt). Erst wird etwas versucht (daher heißt es im Englischen try), und wenn im Fehlerfall ein Exception-Objekt im Programmstück ausgelöst (engl. throw) wird, lässt es sich an einer Stelle auffangen (engl. catch). Da immer die erste passende catch-Klausel ausgewählt wird, darf im Beispiel die letzte catch-Klausel keinesfalls zuerst stehen, da diese auf jede IOException passt, und MalformedURLException ist eine Unterklasse von IOException. Alle anderen Anweisungen in den catch-Blöcken würden dann nicht ausgeführt; der Compiler erkennt dieses Problem und gibt einen Fehler aus.

 

Zum Seitenanfang

8.4.5    Abschlussbehandlung mit finally Zur vorigen ÜberschriftZur nächsten Überschrift

Im Folgenden wollen wir eine optimale Exception-Behandlung programmieren. Es geht im Beispiel darum, die Ausmaße eines GIF-Bildes auszulesen. Das Grafikformat GIF ist sehr einfach und gut dokumentiert, etwa unter http://www.fileformat.info/format/gif/egff.htm. Dort lässt sich erfahren, wie sich die Ausmaße ganz einfach im Kopf einer GIF-Datei ablesen lassen, denn nach den ersten Bytes 'G', 'I', 'F', '8', '7' (oder '9'), 'a' folgen in 2 Bytes an Position 6 und 7 die Breite und an Position 8 und 9 die Höhe des Bildes.

Die ignorante Version

In der ersten Variante schreiben wir den Algorithmus einfach herunter und kümmern uns nicht um die Fehlerbehandlung; mögliche Ausnahmen leitet die statische main(…)-Methode an die JVM weiter:

Listing 8.7    src/main/java/com/tutego/insel/exception/ReadGifSizeIgnoringExceptions.java

import java.io.*;



public class ReadGifSizeIgnoringExceptions {



public static void main( String[] args )

throws FileNotFoundException, IOException {

RandomAccessFile f = new RandomAccessFile( "duke.gif", "r" );

f.seek( 6 );



System.out.printf( "%s x %s Pixel%n", f.read() + f.read() * 256,

f.read() + f.read() * 256 );

}

}

In der Klasse haben wir eine Kleinigkeit noch nicht beachtet: das Schließen des Datenstroms. Das Programm endet mit dem Auslesen der Bytes, aber das Schließen mit close() fehlt. (Das Programm ist klein, und die JVM gibt nach dem Programmende alle nativen Betriebssystemressourcen wieder frei. Da unser Java-Programm aber länger laufen kann, ist es guter Stil, nach dem Abschluss der Dateioperationen Ressourcen zu schließen.) Nehmen wir eine Zeile nach der Konsolenausgabe hinzu:

...

System.out.printf( "%s x %s Pixel%n", f.read() + f.read() * 256,

f.read() + f.read() * 256 );

f.close();

Das close() wiederum kann auch eine IOException auslösen, die jedoch schon über throws in der main-Signatur angekündigt wurde.

Der gut gemeinte Versuch

Dass ein Programm in unserem Fall den main-Thread und damit auch die JVM beendet, sobald eine Datei nicht da ist, ist ein bisschen hart. Daher wollen wir ein try-catch formulieren und die Ausnahme ordentlich abfangen und dokumentieren:

Listing 8.8    src/main/java/com/tutego/insel/exception/ReadGifSizeCatchingExceptions.java

import java.io.*;



public class ReadGifSizeCatchingExceptions {



public static void main( String[] args ) {

try {

RandomAccessFile f = new RandomAccessFile( "duke.gif", "r" );

f.seek( 6 );



System.out.printf( "%s x %s Pixel%n", f.read() + f.read() * 256,

f.read() + f.read() * 256 );

f.close();

}

catch ( FileNotFoundException e ) {

System.err.println( "Datei ist nicht vorhanden!" );

}

catch ( IOException e ) {

System.err.println( "Allgemeiner Ein-/Ausgabefehler!" );

}

}

}

Ist damit alles in Ordnung?

Ab jetzt wird scharf geschlossen

Nehmen wir an, das Öffnen führt zu keiner Ausnahme, doch beim Zugriff auf ein Byte kommt es unerwartet zu einer Ausnahme. Das read() wird abgebrochen, und die JVM leitet uns in den Exception-Block, der eine Meldung ausgibt. Das Problem: Dann schließt das Programm den Datenstrom nicht. Wir könnten verleitet werden, in den catch-Zweig auch ein close() zu schreiben, doch ist das eine Quellcode-Duplizierung, die wir vermeiden müssen. Hier kommt ein finally-Block zum Zuge.

finally-Blöcke stehen immer hinter catch-Blöcken, und ihre wichtigste Eigenschaft ist die, dass der Programmcode im finally-Block immer ausgeführt wird, egal ob es eine Ausnahme gab oder ob es keine Ausnahme gab und die Routine glatt durchlief. Das ist genau, was wir hier bei der Ressourcenfreigabe brauchen. Da finally immer ausgeführt wird, wird die Datei geschlossen (und der interne File-Handle freigegeben), wenn alles gut ging – und ebenso im Fall einer Ausnahme:

Listing 8.9    src/main/java/com/tutego/insel/exception/ReadGifSize.java, main()

RandomAccessFile f = null;



try {

f = new RandomAccessFile( "duke.gif", "r" );

f.seek( 6 );



System.out.printf( "%s x %s Pixel%n", f.read() + f.read() * 256,

f.read() + f.read() * 256 );

}

catch ( FileNotFoundException e ) {

System.err.println( "Datei ist nicht vorhanden!" );

}

catch ( IOException e ) {

System.err.println( "Allgemeiner Ein-/Ausgabefehler!" );

}

finally {

if ( f != null )

try { f.close(); } catch ( IOException e ) { }

}

Da close() eine IOException auslösen kann, muss der Aufruf selbst mit einem try-catch ummantelt werden. Das führt zu etwas abschreckenden Konstruktionen, die TCFTC (try-catch-finally-try-catch) genannt werden. Ein zweiter Schönheitsfehler ist der, dass die Variable f nun außerhalb des try-Blocks deklariert werden muss. Das gibt ihr als lokaler Variablen einen größeren Radius – größer, als er eigentlich sein sollte. Mit einem Extrablock lässt sich das lösen; es sieht aber nicht so hübsch aus. Das spezielle Sprachkonstrukt try mit Ressourcen löst das elegant; Informationen dazu folgen in Abschnitt 8.7.1, »try mit Ressourcen«.

[»]  Hinweis

In einem try-Block deklarierte lokale Variablen sind nicht im angehängten catch- oder finally-Block sichtbar.

Zusammenfassung

Nach einem catch (oder mehreren) kann optional ein finally-Block folgen. Die Laufzeitumgebung führt die Anweisungen im finally-Block immer aus, egal ob eine Ausnahme auftrat oder die Anweisungen im try-Block optimal durchliefen. Das heißt, der Block wird auf jeden Fall ausgeführt – lassen wir System.exit(int) oder Systemfehler einmal außen vor –, auch wenn im try-Block ein return, break oder continue steht oder eine Anweisung eine neue Ausnahme auslöst. Der Programmcode im finally-Block bekommt auch gar nicht mit, ob vorher eine Ausnahme auftrat oder alles glattlief. Wenn das von Interesse ist, müsste eine Anweisung am Ende des try-Blocks ein Flag belegen, was ein Ausdruck im finally-Block dann testen kann.

Sinnvoll sind Anweisungen im finally-Block immer dann, wenn Operationen stets ausgeführt werden sollen. Eine typische Anwendung ist die Freigabe von Ressourcen wie das Schließen von Dateien.

[»]  Hinweis

Es gibt bei Objekten einen Finalizer, doch der hat mit finally nichts zu tun. Der Finalizer ist eine besondere Methode, die immer dann aufgerufen wird, wenn der Garbage-Collector ein Objekt wegräumt.

Ein try ohne catch, aber ein try-finally

Ein try-Block fängt immer Ausnahmen ab, doch nicht zwingend muss ein angehängter catch-Block diese behandeln; throws kann die Ausnahmen einfach nach oben weiterleiten. Nur eine Konstruktion der Art try {} ohne catch ist ungültig, jedoch ist ein try-Block ohne catch, aber mit finally absolut legitim. Diese Konstruktion ist in Java gar nicht so selten, denn sie ist wichtig, wenn eben keine Ausnahme behandelt werden soll, aber unabhängig von möglichen Ausnahmen immer Programmcode abgearbeitet werden soll – ein typisches Beispiel ist die Ressourcenfreigabe.

Kommen wir zu unserem Programm zurück, das die Größe eines GIF-Bildes ermittelt. Wenn beim IO-Fehler nichts zu retten ist, geben wir die Ausnahme an den Aufrufer weiter, versäumen aber nicht, die in der Methode angeforderten Ressourcen wieder freizugeben:

Listing 8.10    src/main/java/com/tutego/insel/exception/ReadGifSizeWithTryFinally.java

import java.io.*;



public class ReadGifSizeWithTryFinally {



public static void printGifSize( String filename )

throws FileNotFoundException, IOException {

RandomAccessFile f = new RandomAccessFile( filename, "r" );



try {

f.seek( 6 );



System.out.printf( "%s x %s Pixel%n", f.read() + f.read() * 256,

f.read() + f.read() * 256 );

}

finally {

f.close();

}

}



public static void main( String[] args )

throws FileNotFoundException, IOException {

printGifSize( "duke.gif" );

}

}

Anstatt im finally-Block die IOException vom close() selbst zu fangen, leiten wir sie in dieser Implementierung auch mit nach oben, wenn es zu einer Ausnahme beim Schließen kommt. Im Beispiel ReadGifSize.java aus Listing 8.9 hatten wir geschrieben:

if ( f != null )

try { f.close(); } catch ( IOException e ) { }

Eine IOException bei close() würde leise versacken, denn der Behandler ist leer. Bei ReadGifSizeWithTryFinally.java wird eine mögliche Ausnahme beim Schließen nach oben geleitet, bei ReadGifSize.java jedoch nicht, denn dort ist der Programmfluss ganz anders.

Aus noch einem Grund ist die Semantik anders, und daher ist von diesem Stil abzuraten, wenn im finally-Block wie bei ReadGifSizeWithTryFinally.java Ausnahmen ausgelöst werden können.

[»]  Wichtig: Java-Verhalten bei multiplen Ausnahmen

Kommt es im try-Block zur Ausnahme und löst auch gleichzeitig der finally-Block eine Ausnahme aus, so wird die Ausnahme im try-Block ignoriert – wir sprechen von einer unterdrückten Ausnahme (engl. suppressed exception). In den Zeilen

try {

throw new Error();

}

finally {

System.out.println( "Geht das?" + 1/0 );

}

kommt die im Kontext uninteressante ArithmeticException durch die Division durch null zum Aufrufer, aber sie unterdrückt den viel wichtigeren harten Error.

Gibt es in unserem Beispiel im try-Block eine Ausnahme und ebenso im finally-Block beim Schließen, dann überdeckt die Schließ-Ausnahme jede andere Ausnahme. Nun ist die Ausnahme im try-Block aber in der Regel wichtiger und sollte nicht verschwinden. Um das Problem zu lösen, gibt es ein anderes Sprachmittel, das Abschnitt 8.7, »Automatisches Ressourcen-Management (try mit Ressourcen)«, vorstellt.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.

Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de



Cookie-Einstellungen ändern