Galileo Computing < openbook >Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Exceptions
7 Äußere.innere Klassen
8 Besondere Klassen der Java SE
9 Generics<T>
10 Architektur, Design und angewandte Objektorientierung
11 Die Klassenbibliothek
12 Einführung in die nebenläufige Programmierung
13 Einführung in Datenstrukturen und Algorithmen
14 Einführung in grafische Oberflächen
15 Einführung in Dateien und Datenströme
16 Einführung in die <XML>-Verarbeitung mit Java
17 Einführung ins Datenbankmanagement mit JDBC
18 Bits und Bytes und Mathematisches
19 Die Werkzeuge des JDK
A Die Klassenbibliothek
Stichwort

Download:
- openbook, ca. 24,5 MB
- Aufgaben, ca. 1,1 MB
- Programme, ca. 12,8 MB
Buch bestellen
Ihre Meinung?

Spacer
Java ist auch eine Insel von Christian Ullenboom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Galileo Computing
1308 S., 10., aktualisierte Auflage, geb., mit DVD
ca. 49,90 Euro, ISBN 978-3-8362-1802-3
Pfeil6 Exceptions
Pfeil6.1 Problembereiche einzäunen
Pfeil6.1.1 Exceptions in Java mit try und catch
Pfeil6.1.2 Eine NumberFormatException auffangen
Pfeil6.1.3 Ablauf einer Ausnahmesituation
Pfeil6.1.4 Eigenschaften vom Exception-Objekt
Pfeil6.1.5 Wiederholung abgebrochener Bereiche *
Pfeil6.1.6 Mehrere Ausnahmen auffangen
Pfeil6.1.7 throws im Methodenkopf angeben
Pfeil6.1.8 Abschlussbehandlung mit finally
Pfeil6.2 RuntimeException muss nicht aufgefangen werden
Pfeil6.2.1 Beispiele für RuntimeException-Klassen
Pfeil6.2.2 Kann man abfangen, muss man aber nicht
Pfeil6.3 Die Klassenhierarchie der Fehler
Pfeil6.3.1 Die Exception-Hierarchie
Pfeil6.3.2 Oberausnahmen auffangen
Pfeil6.3.3 Schon gefangen?
Pfeil6.3.4 Alles geht als Exception durch
Pfeil6.3.5 Zusammenfassen gleicher catch-Blöcke mit dem multi-catch
Pfeil6.4 Harte Fehler: Error *
Pfeil6.5 Auslösen eigener Exceptions
Pfeil6.5.1 Mit throw Ausnahmen auslösen
Pfeil6.5.2 Vorhandene Runtime-Fehlertypen kennen und nutzen
Pfeil6.5.3 Parameter testen und gute Fehlermeldungen
Pfeil6.5.4 Neue Exception-Klassen deklarieren
Pfeil6.5.5 Eigene Ausnahmen als Unterklassen von Exception oder RuntimeException?
Pfeil6.5.6 Ausnahmen abfangen und weiterleiten *
Pfeil6.5.7 Aufrufstack von Ausnahmen verändern *
Pfeil6.5.8 Präzises rethrow *
Pfeil6.5.9 Geschachtelte Ausnahmen *
Pfeil6.6 Automatisches Ressourcen-Management (try mit Ressourcen)
Pfeil6.6.1 try mit Ressourcen
Pfeil6.6.2 Ausnahmen vom close() bleiben bestehen
Pfeil6.6.3 Die Schnittstelle AutoCloseable
Pfeil6.6.4 Mehrere Ressourcen nutzen
Pfeil6.6.5 Unterdrückte Ausnahmen *
Pfeil6.7 Besonderheiten bei der Ausnahmebehandlung *
Pfeil6.7.1 Rückgabewerte bei ausgelösten Ausnahmen
Pfeil6.7.2 Ausnahmen und Rückgaben verschwinden: Das Duo »return« und »finally«
Pfeil6.7.3 throws bei überschriebenen Methoden
Pfeil6.7.4 Nicht erreichbare catch-Klauseln
Pfeil6.8 Den Stack-Trace erfragen *
Pfeil6.8.1 StackTraceElement
Pfeil6.8.2 printStackTrace()
Pfeil6.8.3 StackTraceElement vom Thread erfragen
Pfeil6.9 Assertions *
Pfeil6.9.1 Assertions in eigenen Programmen nutzen
Pfeil6.9.2 Assertions aktivieren
Pfeil6.10 Zum Weiterlesen

Galileo Computing - Zum Seitenanfang

6.4 Harte Fehler: Error *

Fehler, die von der Klasse java.lang.Error abgeleitet sind, stellen Fehler dar, die mit der JVM in Verbindung stehen. Anders reagieren dagegen die von Exception abgeleiteten Klassen – sie stehen für eigene Programmfehler. Beispiele für konkrete Error-Klassen sind:

Im Fall von ThreadDeath lässt sich ableiten, dass nicht alle Error-Klassen auf »Error« enden. Das liegt sicherlich auch daran, dass das nicht ein Fehler im eigentlichen Sinne ist, denn die JVM löst ThreadDeath aus, wenn das Programm einen Thread mit stop() beenden will.

Da ein Error »abnormales« Verhalten anzeigt, müssen Operationen, die einen solchen Fehler auslösen können, auch nicht in einem try-Block sitzen oder mit throws nach oben weitergegeben werden (Error-Fehler zählen zu den nicht geprüften Ausnahmen, obwohl Error keine Unterklasse von RuntimeException ist!). Allerdings ist es möglich, die Fehler aufzufangen, da Error-Klassen Unterklassen von Throwable sind und sich daher genauso behandeln lassen. Insofern ist ein Auffangen legitim, und auch ein finally ist korrekt. Ob das Auffangen sinnvoll ist, ist eine andere Frage, denn wenn die JVM einen Fehler anzeigt, bleibt offen, wie darauf sinnvoll zu reagieren ist. Was sollten wir bei einem LinkageError tun? Einen OutOfMemoryError in bestimmten Programmteilen aufzufangen, kann jedoch von Vorteil sein. Eigene Unterklassen von Error sollten keine Anwendung finden. Glücklicherweise sind die Klassen aber nur Unterklassen von Throwable und nicht von Exception, sodass ein catch(Exception e) nicht aus Versehen Dinge wie ThreadDeath abfängt, die eigentlich nicht behandelt gehören.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.







<< zurück
  Zum Katalog
Zum Katalog: Java ist auch eine Insel





Java ist auch eine Insel
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java 7 – Mehr als eine Insel





 Java 7 –
 Mehr als eine Insel


Zum Katalog: Android 3






 Android 3


Zum Katalog: Android-Apps entwickeln






 Android-Apps
 entwickeln


Zum Katalog: NetBeans Platform 7






 NetBeans
 Platform 7


Zum Katalog: Einstieg in Eclipse 3.7






 Einstieg in
 Eclipse 3.7


Zum Katalog: Einstieg in Java






 Einstieg
 in Java


Zum Katalog: Einstieg in Java 7






 Einstieg in
 Java 7


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
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.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de