Sep 13

Auch Exceptions können erneut geworfen werden. Während RuntimeExceptions und deren Unterklassen analog zu Errors erneut geworfen werden, gibt es eine Besonderheit bei allen anderen Exceptions:

class Angestellter {


static void test () throws IOException{

throw new IOException();

}

public static void main(String args[]) throws IOException {


try {

test();

}
catch (IOException e) { throw e; }

catch (Exception e) { }


}

}

Um diese Exception erneut werfen zu können, muss dies in der werfenden Methode (hier: main) definiert sein.

Sind mehrere catch-Klauseln vorhanden, die auch auf die erneut geworfene Exception passen würden (hier: catch (Exception e) { } ) werden diese ignoriert.

Tagged with:
Sep 05

Eigene Exceptions können sehr einfach durch Erweiterung einer bestehenden Klasse definiert werden:

class NeueException extends IOException { … }

Alles andere wird wie gewohnt behandelt:

class Angestellter {


static void test () throws NeueException {

throw new NeueException ();

}

public static void main(String args[]) {

try {

test();

}
catch (Exception e){ e.printStackTrace(); }

}

}

Auch hier wieder die Unterscheidung zwischen (Un-)checked Exceptions; bei Ableitung von der Klasse RuntimeException bzw. deren Unterklassen ist die Definition im Methoden-Header und der try/catch/finally-Block nicht notwendig.

Tagged with:
Sep 03

RuntimeExceptions und deren Unterklassen können, müssen aber (im Gegensatz zu allen anderen Exceptions) nicht im Methoden-Header definiert werden; somit ist

static void test()  { throw new NullPointerException(); }

gleichbedeutend mit

static void test() throws NullPointerException { throw new NullPointerException(); }

Wie bei RuntimeExceptions und deren Unterklassen generell üblich, können die Methodenaufrufe in try/catch/finally-blocks gepackt werden, müssen aber nicht. Die Aufrufe von main oder auch einer anderen Methode

test();

und

try { test();} catch (NullPointerException e) { … }

sind somit beide gleichbedeutend.

Somit werden RuntimeExceptions und deren Unterklassen auch unchecked Exceptions genannt, weil hier eine zwingende Überprüfung nicht nötig ist.

Im Gegensatz hierzu werden alle anderen Exceptions, die nicht von RuntimeExceptions abgeleitet sind checkedExceptions genannt. Bei checked Exceptions führt ein fehlender try/catch/finally-Block oder eine fehlende Deklaration über eine zu werfende Exception zu einem CompilerFehler.

Tagged with:
Sep 01

Da ja jede Methode ihre aufgefangenen Exceptions weitergibt an die aufrufende Methode/ main, muss auch die potentiell auffangende Methode definieren, dass sie ggfs eine Exception wirft:

class Angestellter {

int PersNr;

void setPersNr(int PersNr) throws IOException { // Hier nichts neues; Information, dass Methode IOException wirft

if (PersNr > 1000)

throw new IOException(); // Werfen der Exception

else

this.PersNr=PersNr;

}

void handlePersNr (int PersNr) throws IOException{ // Information, dass diese Methode ebenfalls eine IOException werfen kann, die sie von setPersNr auffängt

setPersNr (PersNr);

}

public static void main(String args[]) {

Angestellter a = new Angestellter();

try {

a.handlePersNr(1000);

}

catch (IOException e){ e.printStackTrace(); } // Auffangen der Exception


}

}

Tagged with:
Aug 29

Vielleicht fragt sich der eine oder andere, wie der Compiler weiß, welche Exception er aufnehmen muss; es ist relativ einfach: Mit Ausnahme der RuntimeException müssen diese deklariert werden:

class Angestellter {

int PersNr;

void setPersNr(int PersNr) throws IOException { // Deklarierung, dass diese Methode einen Fehler wirft

if (PersNr > 1000)

throw new IOException();// Werfen des Fehlers

else

this.PersNr=PersNr;

}

public static void main(String args[]) {


Angestellter a = new Angestellter();

try { // Unerlässlicher try-Block; weglassen führt zu CompilerFehler

a.setPersNr(1001)  ;

} catch (IOException e){ e.printStackTrace(); } // Auffangen des Fehlers und Ausgabe der Fehlermeldungen


}

}

Tagged with:
Aug 25

Heute möchte ich ein wenig auf die Hierarchie(n) von Exceptions eingehen:

alternativer Text

An oberster Stelle steht die Klasse Throwable, die (wie alle Klassen) eine Sub-Klasse von Object ist.

Fehler/Errors sind Probleme, die zur Laufzeit nicht behandelt werden können, z.B. fehlender Speicherplatz (OutofMemoryError) und direkt zum Absturz des Programms führen.

Exceptions/ Ausnahmen sind behandelbare Probleme, z.B. kann (im Gegensatz zu Errors) bei einem abgefangenen NullPointer problemlos weitergearbeitet werden; ohne Speicherplatz (bei Error) aber nicht.

RuntimeExeption ist eine Basisklasse für alle Exceptions, die zur Laufzeit auftreten. Sie entstehen durch Fehler, die der Programmierer selbst verursacht hat.  Von dieser Klasse sind weitere, differenziertere Exceptions (z.B. NullPointerException, ArithmeticException, …) abgeleitet.

Eine andere von Exeption abgeleitete Klasse, ist z.B. java.io.IOException, die sowie deren abgeleitete Klassen ( z.B. java.io.FileNotFoundException) z.B. bei der Arbeit mit Dateien angewandt werden kann.

Die Implementierung dieser Hierarchie sieht folgendermaßen aus:

try { ….  }
catch (ArithmeticException e){ …  } // fängt ArithmeticExeptions auf
catch (NullPointerException e) {  … } // fängt NullPointerExceptions auf
catch (RuntimeException e) {  …  } // fängt RunTimeExeptions auf
catch (Exception e){ … } // fängt alle Exceptions auf

Die Reihenfolge muss  immer entgegengesetzt der Hierarchie sein; da Exception ja alles auffängt und die weiteren catch dann nicht mehr beachtet und damit überflüssig wären. Der Compiler erkennt dies und gibt einen CompilerFehler aus.

Grundsätzlich ist es nicht ratsam alle mit catch (Exception e) alle Exceptions aufzufangen, da auch unvorhergesehene Fehler auftreten können, die der Programmierer (und somit später das Programm) nicht berücksichtigen.

Tagged with:
Aug 23

Exceptions sind immer eine Unterklasse von java.lang.Exception. Ich habe schon häufiger im catch-block

catch (Exception e) { … } oder catch (ArithmeticException e){ … }

geschrieben und möchte heute auf den Inhalt zwischen den Klammern etwas näher eingehen:

e ist in diesem Falle eine Instanz der Klasse Exception, bzw. ArithmeticException (oder jeder anderen Klasse, deren Exception aufgefangen wird), dessen Methoden wie bei jeder anderen Klasse aufgerufen werden können.

Eine sehr häufige Methode ist printStackTrace(), welche die Ausgabereihenfolge bei nicht-Abfangen einer Exception kontrolliert ausgibt. Wichtig in diesem Zusammenhang ist auch, dass leere geschweifte Klammern durchaus erlaubt, aber relativ nutzlos sind.

catch (Exception e) {  }

nimmt fängt zwar die Fehler, aber macht nichts damit.  Ohne e.printStackTrace oder andere Informationen/Maßnahmen wird dieser Fehler versteckt und nicht sichtbar gemacht.

Tagged with:
Aug 21

Für den Fall, dass eine Methode eine Exception wirft, die von einer anderen Methode aufgerufen wird, wird die Exception bis ans Hauptprogramm durchgereicht.

class Angestellter {

static void test() { test2(); }

static void test2 () { test3(); }

static void test3 () { int i = 1/0; }

public static void main(String args[]) {

test();
}

}

Der Methodenaufruf ist wie folgt:

main -> test() -> test2() -> test 3; die Exception wird in test3 geworfen. Da in unserem Beispiel diese Ausnahme nicht abgefangen und behandelt wird führt diese zu einem Programmabsturz. Jede Methode informiert ihre jeweils aufrufende Methode über die aufgetretene Exception.

Die Ausgabe ist wie folgt:

Exception in thread “main” java.lang.ArithmeticException: / by zero
at Angestellter.test3(Angestellter.java:15)
at Angestellter.test2(Angestellter.java:13)
at Angestellter.test(Angestellter.java:11)
at Angestellter.main(Angestellter.java:18)

Somit kann an der Ausgabereihenfolge auch sehr gut erkannt werden, von wo (Fehlerquelle zuerst) nach wo (Endpunkt zuletzt) der Fehler aufgetreten ist und weitergegeben wurde. Der Methodenaufruf wird also umgekehrt dargestellt.

Tagged with:
Aug 19

Nochmal ganz kurz eine Übersicht der Blöcke:

try – “Versuchsblock” – alles was später abgefangen werden soll oder sogar muss (z.B. bei bestimmten Java-Methoden ist dies zwingend) wird hierin eingeschlossen

catch – “Auffangblock” – Auffangen aller oder nur bestimmter Exceptions

finally – “Aufräumblock” – Dieser Block läuft immer, unabhängig ob Exceptions geworfen worden sind oder nicht. Selbst ein return zur aufrufenden Methode hat keinen Einfluss auf die finally-Ausführung.

Nun noch ein paar Besonderheiten:

Ein try-Block muss immer mindestens mit catch oder finally abgeschlossen werden;

try { … }

führt daher zu einem CompilerFehler; erlaubt ist

try { … } catch (Exception) { … }

try { … } finally { … }

try { … } catch (Exception) { … } finally { … }

Auch darf kein anderer Code zwischen diesen Blöcken eingefügt werden:

try { }
System.out.println(“DoSomething”);
// CompilerFehler
catch (Exception e) {  … }

Tagged with:
Aug 17

finally wird wirklich immer aufgerufen, selbst wenn aus dem Unterprogramm ins Hauptprogramm mit return zurückgekehrt werden soll.

class Angestellter {

static void test() {

File datei = new File(“Test.txt”);

try {

int [] a = new int [4];
a[3]=1;
return;
// Rückkehr zur main

}catch (Exception e){

System.out.println(“Exception aufgefangen”);

}

finally { // wird sogar bei/vor return aufgerufen

System.out.println(“In finally”);

}

System.out.println(“Nach Finally”);

}

public static void main(String args[]) {


System.out.println(“Aufruf Methode” );
test();
System.out.println(“Nach Methodenaufruf”);


}


}

Die Ausgabe ist demnach:

Aufruf Methode
In finally
Nach Methodenaufruf

Vor dem Verlassen der Methode wird also noch finally aufgerufen.

Für den Fall, das die Exception ausgelöst wird, ist die Ausgabe:

Aufruf Methode
Exception aufgefangen
In finally
Nach Finally
Nach Methodenaufruf

Grund für die veränderte ausgabe ist, das der try-Block beim Auswurf einer Exception nicht weiter ausgeführt und in unserem Beispiel return nicht mehr gelesen wird.  Somit wird der Rest des Codes und nicht return ausgeführt.

Tagged with:
preload preload preload
http://www.wikio.de Blog Top Liste - by TopBlogs.de Blogverzeichnis - Blog Verzeichnis bloggerei.de Bloggeramt.de Software
Webbhotell Top Blogs