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

Pfeil 8 Ausnahmen müssen sein
Pfeil 8.1 Problembereiche einzäunen
Pfeil 8.1.1 Exceptions in Java mit try und catch
Pfeil 8.1.2 Geprüfte und ungeprüfte Ausnahmen
Pfeil 8.2 Geprüfte Ausnahmen
Pfeil 8.2.1 Letzte ausgeführte Java-Programme loggen
Pfeil 8.2.2 try-catch-Behandlung
Pfeil 8.2.3 throws im Methodenkopf angeben
Pfeil 8.3 Ungeprüfte Ausnahmen (RuntimeException)
Pfeil 8.3.1 Eine NumberFormatException fliegt
Pfeil 8.3.2 Bekannte RuntimeException-Klassen
Pfeil 8.3.3 Kann man abfangen, muss man aber nicht
Pfeil 8.4 Gut gefangen
Pfeil 8.4.1 Bitte nicht schlucken – leere catch-Blöcke
Pfeil 8.4.2 Wiederholung abgebrochener Bereiche *
Pfeil 8.4.3 Mehrere Ausnahmen auffangen
Pfeil 8.4.4 Ablauf einer Ausnahmesituation
Pfeil 8.4.5 Abschlussbehandlung mit finally
Pfeil 8.5 Die Klassenhierarchie der Ausnahmen
Pfeil 8.5.1 Eigenschaften des Exception-Objekts
Pfeil 8.5.2 Basistyp Throwable
Pfeil 8.5.3 Die Exception-Hierarchie
Pfeil 8.5.4 Oberausnahmen auffangen
Pfeil 8.5.5 Schon gefangen?
Pfeil 8.5.6 Alles geht als Exception durch
Pfeil 8.5.7 Zusammenfassen gleicher catch-Blöcke mit dem multi-catch
Pfeil 8.6 Auslösen eigener Exceptions
Pfeil 8.6.1 Mit throw Ausnahmen auslösen
Pfeil 8.6.2 Vorhandene Runtime-Ausnahmetypen kennen und nutzen
Pfeil 8.6.3 Parameter testen und gute Fehlermeldungen
Pfeil 8.6.4 Neue Exception-Klassen deklarieren
Pfeil 8.6.5 Eigene Ausnahmen als Unterklassen von Exception oder RuntimeException?
Pfeil 8.6.6 Ausnahmen abfangen und weiterleiten *
Pfeil 8.6.7 Aufruf-Stack von Ausnahmen verändern *
Pfeil 8.6.8 Präzises rethrow *
Pfeil 8.6.9 Geschachtelte Ausnahmen *
Pfeil 8.7 Automatisches Ressourcen-Management (try mit Ressourcen)
Pfeil 8.7.1 try mit Ressourcen
Pfeil 8.7.2 Die Schnittstelle AutoCloseable
Pfeil 8.7.3 Mehrere Ressourcen nutzen
Pfeil 8.7.4 try mit Ressourcen auf null-Ressourcen
Pfeil 8.7.5 Ausnahmen vom close()
Pfeil 8.7.6 Unterdrückte Ausnahmen *
Pfeil 8.8 Besonderheiten bei der Ausnahmebehandlung *
Pfeil 8.8.1 Rückgabewerte bei ausgelösten Ausnahmen
Pfeil 8.8.2 Ausnahmen und Rückgaben verschwinden – das Duo return und finally
Pfeil 8.8.3 throws bei überschriebenen Methoden
Pfeil 8.8.4 Nicht erreichbare catch-Klauseln
Pfeil 8.9 Harte Fehler – Error *
Pfeil 8.10 Assertions *
Pfeil 8.10.1 Assertions in eigenen Programmen nutzen
Pfeil 8.10.2 Assertions aktivieren und Laufzeit-Errors
Pfeil 8.10.3 Assertions feiner aktivieren oder deaktivieren
Pfeil 8.11 Zum Weiterlesen
 

Zum Seitenanfang

8.10    Assertions * Zur vorigen ÜberschriftZur nächsten Überschrift

Die Übersetzung des englischen Wortes assertion lässt vermuten, worum es geht: um Zusicherungen. Assertions formulieren Aussagen, die beim korrekten Ablauf des Codes immer wahr sein müssen. Ist eine Bedingung nicht erfüllt, folgt eine Ausnahme, die darauf hinweist, dass im Programm etwas falsch gelaufen sein muss. Der Einsatz von Assertions im Code fördert die Dokumentation für den gültigen Programmzustand. Wir unterscheiden:

  • Precondition: Zustand, der vor einer Operation immer wahr sein muss

  • Postcondition: Zustand, der nach einer Operation immer wahr sein muss

Die Formulierung korrekter Zustände ist ein wesentliches Element von Design by Contract, einer Entwicklungsmethode, bei der es darum geht, einen »Vertrag« (engl. contract) aufzustellen über das, was ein Programm leisten muss. Bertrand Meyer, auch Erfinder der Programmiersprache Eiffel, prägte diesen Begriff.

 

Zum Seitenanfang

8.10.1    Assertions in eigenen Programmen nutzen Zur vorigen ÜberschriftZur nächsten Überschrift

Java-Programme nutzen für Assertions im Quellcode die assert-Anweisung. Es gibt zwei Varianten, eine mit und eine ohne Meldung:

assert AssertConditionExpression;

assert AssertConditionExpression : MessageExpression;

AssertConditionExpression steht für ein Prädikat, das zur Laufzeit ausgewertet wird. Der Ausdruck wird nicht automatisch geklammert, da er sich nicht wie ein Methodenaufruf liest.

[»]  Java-Geschichte

Neue Schlüsselwörter wurden immer wieder eingeführt: in Java 1.3 das Schlüsselwort strictfp, in Java 1.4 das Schlüsselwort assert für die »Behauptungen« und in Java 5 Aufzählungstypen mit dem neuen Schlüsselwort enum.

 

Zum Seitenanfang

8.10.2    Assertions aktivieren und Laufzeit-Errors Zur vorigen ÜberschriftZur nächsten Überschrift

Assertions stehen immer in der Klassendatei, da der Compiler sie immer in Bytecode abbildet. Jedoch werden Assertions zur Laufzeit standardmäßig nicht beachtet, da sie abgeschaltet sind. Somit entsteht kein Geschwindigkeitsverlust bei der Ausführung der Programme. Um Assertions zu aktivieren, muss die Laufzeitumgebung mit dem Schalter -ea (enable assertions) gestartet werden.

Sind Assertions aktiviert und wertet die JVM das Ergebnis der assert-Anweisungen zu true aus, führt die Laufzeitumgebung die Abarbeitung normal weiter. Ergibt die Auswertung false, wird das Programm mit einem java.lang.AssertionError beendet. Wir haben gesehen, dass es zwei Varianten gibt:

assert AssertConditionExpression;

assert AssertConditionExpression : MessageExpression;

Der optionale zweite Parameter, MessageExpression, ist ein Text, der beim Stack-Trace als Nachricht in der Fehlermeldung erscheint. Die in Java ausgelösten Ausnahmen sind vom Typ »Error« und nicht vom Typ »Exception« und sollten daher auch nicht aufgefangen werden, da eine nicht erfüllte Bedingung ein Programmierfehler ist.

[»]  Hinweis

Die JVM ignoriert Assertions standardmäßig bei der Ausführung, und eine Aktivierung erfolgt nur auf Befehl. Ein Ablauf ohne Bedingungstests ist eher der Normalfall. Daraus folgt, dass Ausdrücke in den assert-Anweisungen ohne Nebeneffekte sein müssen. So etwas wie

assert counter-- == 0;

ist keine gute Idee, denn das Vermindern der Variablen ist ein Nebeneffekt, der nur dann stattfindet, wenn die JVM auch Assertions aktiviert hat. Allerdings lässt sich das auch für einen Trick nutzen, um Assertions bei der Ausführung zu erzwingen. Im statischen Initialisierer einer Klasse können wir Folgendes setzen:

boolean assertEnabled = false;

assert assertEnabled = true;

if ( ! assertEnabled )

throw new RuntimeException( "Assertions müssen aktiviert werden" );

Beispiel

Eine eigene statische Methode subAndSqrt(double, double) bildet die Differenz zweier Zahlen und zieht aus dem Ergebnis die Wurzel. Natürlich weiß jeder Entwickler, dass die Wurzel aus negativen Zahlen nicht erlaubt ist, aber dennoch ginge so etwas in Java durch, nur ist das Ergebnis ein NaN. Sollte irgendein Programmteil nun die Methode subAndSqrt(double, double) mit einem falschen Paar Zahlen aufrufen und das Ergebnis NaN sein, muss ein Assert-Error erfolgen, da es einen internen Programmfehler zu korrigieren gilt:

Listing 8.34    src/main/java/com/tutego/insel/assertion/AssertKeyword.java, Ausschnitt

public class AssertKeyword {



public static double subAndSqrt( double a, double b ) {

double result = Math.sqrt( a - b );



assert ! Double.isNaN( result ) : "Berechnungsergebnis ist NaN!";



return result;

}



public static void main( String[] args ) {

System.out.println( "Sqrt(10-2)=" + subAndSqrt(10, 2) );

System.out.println( "Sqrt(2-10)=" + subAndSqrt(2, 10) );

}

}

Rufen wir das Programm mit dem Schalter -ea auf:

$ java -ea com.tutego.insel.assertion.AssertKeyword

Die Ausgabe ist dann:

Sqrt(10-2)=2.8284271247461903

Exception in thread "main" java.lang.AssertionError: Berechnungsergebnis ist NaN!

at com.tutego.insel.assertion.AssertKeyword.subAndSqrt(AssertKeyword.java:8)

at com.tutego.insel.assertion.AssertKeyword.main(AssertKeyword.java:15)
Unter »File • Project Properties« kann der VM-Schalter für die Assertions gesetzt werden.

Abbildung 8.13    Unter »File • Project Properties« kann der VM-Schalter für die Assertions gesetzt werden.

Wurde das Programm in Eclipse schon gestartet, kann im Menü »Run • Run Configurations …« unterhalb des Reiters »Arguments« bei den »VM arguments« der Schalter »-ea« gesetzt werden.

Abbildung 8.14    Wurde das Programm in Eclipse schon gestartet, kann im Menü »Run • Run Configurations …« unterhalb des Reiters »Arguments« bei den »VM arguments« der Schalter »-ea« gesetzt werden.

 

Zum Seitenanfang

8.10.3    Assertions feiner aktivieren oder deaktivieren Zur vorigen ÜberschriftZur nächsten Überschrift

Assertions müssen nicht global für das ganze Programm gesetzt werden, sondern können auch feiner deklariert werden, etwa für eine Klasse oder ein Paket. Mit geschickter Variation von –ea (Assertions aktivieren) und –da (Assertions deaktivieren) lässt sich sehr gut steuern, was die Laufzeitumgebung prüfen soll.

[zB]  Beispiel

Aktiviere Assertions für die Klasse com.tutego.App:

$ java -ea:com.tutego.App  ClassWithMain

Aktiviere Assertions für das Default-Paket (dafür stehen die drei Punkte):

$ java -ea:...  ClassWithMain

Aktiviere Assertions für das Paket com.tutego inklusive aller Unterpakete (auch dafür stehen drei Punkte):

$ java -ea:com.tutego...  ClassWithMain

Aktiviere Assertions für das Paket com.tutego inklusive aller Unterpakete, aber deaktiviere sie für die Klasse App in dem Paket com.tutego:

$ java -ea:com.tutego... -da:com.tutego.App  ClassWithMain

 


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