Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- q1:java-trycatch [2017/09/20 09:28] – admin03
+++ q1:java-trycatch [2017/09/20 09:38] (aktuell) – admin03
@@ Zeile 22: / Zeile 22: @@
 Wie in anderen Programmen auch, so können in Java-Programmen natürlich Fehler auftreten. Nach ihrem Schweregrad werden sie in zwei Hauptkategorien eingeteilt:
-    Errors sind Fehler, die meist durch Fehlfunktionen der JVM ausgelöst werden, zum sofortigen Abbruch der Programmausführung führen und nicht abgefangen werden.
+**Errors** sind Fehler, die meist durch Fehlfunktionen der
-    Exceptions (Ausnahmen) sind Fehler, die meist durch das Programm selbst (Konvertierungsprobleme, Typisierungsfehler etc.) oder unvorhergesehene Änderungen der Ausführungsbedingungen (Netzwerkabriss, Dateisystemfehler, etc.) ausgelöst werden können und gesichert abgefangen werden müssen.
+JVM ausgelöst werden, zum sofortigen Abbruch der
+Programmausführung führen und nicht abgefangen werden.
+**Exceptions** (Ausnahmen) sind Fehler,
+die meist durch das Programm selbst
+(Konvertierungsprobleme, Typisierungsfehler etc.)
+oder unvorhergesehene Änderungen der Ausführungsbedingungen
+(Netzwerkabriss, Dateisystemfehler, etc.)
+ausgelöst werden können und gesichert abgefangen werden müssen.
+<code JAVA>
+BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
+int i = 0;
+try {
+    i = new Integer(reader.readLine());
+} catch (IOException e) {
+    e.printStackTrace();
+}
+</code>
+Hier wird eine Eingabe von der Konsole gelesen, als int gespeichert und ausgegeben. Das geht so lange gut, wie auch ein numerischer Wert eingegeben wird. Beim Auslesen von alphanumerischen Werten wird hingegen eine java.util.NumberFormatException ausgelöst, da ein solches Literal nicht in einen numerischen Wert gewandelt werden kann. Ginge man nun her und würde diesen Fall lediglich durch einen try-catch-Block absichern, so wären zwar Fehler abgesichert, ein sinnvoller Programmablauf selbst wäre jedoch nicht unbedingt gegeben, da die Applikation ohne Behandlung der Eingabe weiterlaufen würde. Die falsche Belegung der Variablen könnte im weiteren Verlauf u.U. zu schwerwiegenden Fehlfunktionen führen.
+===== Mehrfache Catches =====
+Was kann noch so alles passieren?. Wenn wir eine Datei öffnen wollen, kann es z.B. sein, das sie gar nicht mehr exsistiert oder möglicherweise auch nicht lesbar, dann gibt es zwei unterschiedliche Exceptions die jeweis in der richtigen Reihenfolge bearbeitet werden müssen:
+<code 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!" );
+    }
+  }
+}
+</code>
+===== Finally =====
+<code JAVA>
+try
+{
+  ANWEISUNGSBLOCK
+}
+catch (AUSNAHME 1)
+{
+  ANWEISUNGSBLOCK
+}
+catch (AUSNAHME 2)
+{
+  ANWEISUNGSBLOCK
+}
+FINALLY
+{
+  ANWEISUNGSBLOCK DER IMMER AM ENDE AUSGEFÜHRT WIRD
+}
+</code>
+Nach einem (oder mehreren) catch kann optional ein finally-Block folgen. Die Laufzeitumgebung führt die Anweisungen im finally-Block immer aus, egal, ob ein Fehler auftrat oder die Anweisungen im try-catch-Block optimal durchliefen. Das heißt, der Block wird auf jeden Fall ausgeführt – lassen wir System.exit() oder Systemfehler einmal außen vor –, auch wenn im try-catch-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.