Best Practice verschiedene Exceptions fangen und neue Exception erzeugen

[Sergeant_Pepper]

Hallo,

es gibt ja häufig die Situation, dass hiner einem try-Block 5 oder mehr catch-Blöcke folgen.

Mein Kollege und ich (beide Java-Quereinsteiger, keine Informatiker) überlegen und diskutieren nun, ob und wie wir diese Exceptions zusammenfassen, bzw. eine neue Exception erzeugen, weil die höhere Programmebene nur wissen muss, dass es ein Ausnahme gegeben hat.

Mein Kollege schlägt nun folgendes Prinzip vor:

try
{
    /* Anweisungen */
}
catch (FileNotFoundException ef)
{
       throw new Exception(
                   "Die Auftragsdatei wurde nicht gefunden:\n", ef);
}
catch (IOException ei)
{
       throw new Exception(
                 "Input/Output-Fehler beim Parsen der Auftragsdatei:\n",
                    ei);
}
catch (JDOMException ej)
{
       throw new Exception(
                 "Fehler (JDOM) beim Parsen der Auftragdatei:\n",
                 ej);
}

Einerseits finde ich den Gedanken richtig, mehrere Exceptions zu bündeln, um "oben" das Handling zu vereinfachen. Aber kann es sinnvoll sein, für die Vereinfachung die Basisklasse Exception zu verwenden?

 

[Michael...]

weil die höhere Programmebene nur wissen muss, dass es ein Ausnahme gegeben hat.

Im Prinzip scheint es aber doch relevant zu sein, was für eine Exception aufgetreten ist!?

Irgendwie ist mir auch nicht klar welchen Vorteil das "Prinzip" bringen soll. Wenn die höhere Programmebene tatsächlich nur wissen muss, dass eine Exception aufgetreten ist, würde ja ein

throws Exception

an der Methode ausreichen.

 

[Sergeant_Pepper]

Das Programm soll in aller Regel nach der Ausnahme beendet werden. Über das Konstrukt

[EDIT]throw[/EDIT] new Exception("Beschreibung", nf)

können wir die auslösende Ausnahme als "Info", z.B. für das Logging, hinzufügen. Mit

throws

hinter der Signatur ginge das nicht.

Ich habe nur Zweifel, ob wir das mit

new Exception()

richtig machen, oder ob wir nicht eine eigene Exception-Klasse benutzen sollten.

 

[D4rkscr43m]

Wieso fangt ihr die Ausnahme denn überhaupt ab?

Einfach nur

public void meineMethode() throws Exception { /* hier dein Code der eine Ausnahme auslösen kann */ }

Würde doch reichen. Wenn eine Ausnahme ausgelöst wird, wird diese einfach an die aufrufende Methode weiter geleitet.

 

[Sergeant_Pepper]

Wieso fangt ihr die Ausnahme denn überhaupt ab?

Warum wir das möchten, habe ich meinem Posting von 16:05 Uhr beschrieben.

 

[D4rkscr43m]

Warum wir das möchten, habe ich meinem Posting von 16:05 Uhr beschrieben.

hast du nicht!

Du sagst, du möchtest das Programm nach einer Ausnahme beenden lassen.
Wieso sollte das nicht mit meinem Vorschlag gehen?

ALLE Ausnahmen SIND Exceptions, dass heißt, ob da nun eine FileNotFoundException, eine IOException oder einfach eine Exception fliegt, ist der Aufrufenden Methode egal, die Signatur sagt ihr, dass da eine Exception kommen kann und was für eine das ist, kann ja gerne gelogt werden, aber das kann der aufrufenden Methode weiterhin herzlich egal sein.

 

[Sergeant_Pepper]

doch habe ich beschrieben (habe eben nur das Wort

throw

eingefügt):

Über das Konstrukt throw new Exception("Beschreibung", nf) können wir die auslösende Ausnahme als "Info", z.B. für das Logging, hinzufügen. Mit throws hinter der Signatur ginge das nicht.

 

[D4rkscr43m]

Wenn es sich dabei nur um eine Abbruchbedingung handelt sind folgende Quelltexte gleichwertig:

public void dosomething() throws Exception {
try
{
    /* Anweisungen */
}
catch (FileNotFoundException ef)
{
       throw new Exception(
                   "Die Auftragsdatei wurde nicht gefunden:\n", ef);
}
catch (IOException ei)
{
       throw new Exception(
                 "Input/Output-Fehler beim Parsen der Auftragsdatei:\n",
                    ei);
}
catch (JDOMException ej)
{
       throw new Exception(
                 "Fehler (JDOM) beim Parsen der Auftragdatei:\n",
                 ej);
}
}

public void dosomething() throws Exception {
    /* Anweisungen */
}

Und selbst für das Logging reicht das aus, weil die Exception die geworfen wird ja immer noch eine FileNotFoundException, IOException oder JDOMException ist.

 

[Sergeant_Pepper]

Und selbst für das Logging reicht das aus, weil die Exception die geworfen wird ja immer noch eine FileNotFoundException, IOException oder JDOMException ist.

OK ... an diesen Aspekt hatte ich nicht gedacht. Danke!

Also könnte man das durchaus so machen, dass man spezialisierte Ausnahmen zur Klasse "Exception" umformt? Beim Google'n habe ich einige Stellen gefunden, wo davon abgeraten wird , konkrete Exception-Objekte zu erzeugen und zu fangen, z.B.
Best Practices for Exception Handling - O'Reilly Media und
10 best practices with Exceptions - WikiJava, exception, error, handling, throw, throwable

 

[TKausL]

Also könnte man das durchaus so machen, dass man spezialisierte Ausnahmen zur Klasse "Exception" umformt?

Man formt sie nicht um.
Alle Exceptions leiten von "Exception" ab. D.h. es ist nur ein interner cast zur Vaterklasse.
Natürlich "solltest" du die Exceptions alle einzeln behandeln. Fals du aber sowieso bei ALLEN Exceptions gleich reagierst kannst du auch einfach alles gebündelt als catch(Exception e) behandeln.

 

[newcron]

VORSICHT:
"throws Exception" ist tatsächlich ein antipattern und *nicht* alle Exceptions sind gleich. Eine solche Aussage kostet einem Software Entwickler in einem Jobinterview definitiv die Chance auf einen neuen Arbeitsplatz.

Manche kann man behandeln, manche eben nicht. Bricht einem Webserver eine Datenbankverbindung weg, kann der vermutlich nicht so recht drauf reagieren, außer, internal server errors auszuspielen. Sollte ein nutzer in einer Desktop Anwendung allerdings eine Datei auswählen und hat stattdessen einen Ordner ausgewählt, kann man ihn vielleicht mit einem fehlerdialog darauf hinweisen.

Exceptions einfach blind weiterfliegen zu lassen, ist mitunter gefährlich, da man prinzipiell Fehlerursachen verschleiert und irgendwann nicht mehr weiß, welche Exceptions überhaupt fliegen könnten - es wirft ja alles einfach nur ne Exception.

Die modernere Vorgehensweise ist, Exceptions, die wirklich nicht behandelt werden können, in RuntimeExceptions zu wrappen. Die müssen weder gefangen noch deklariert werden und treten unter normalen umständen auch nicht auf. Wenn sie dann doch auftreten sollte man nur sicherstellen, dass sie einen Logeintrag oder einen Alarm triggern (vor allem, wenn es sich um eine Serveranwendung handelt). Generell gilt als gesichert, dass die Art, wie Java mit Exceptions umgeht nicht ganz optimal ist - bei vielen Exceptions die im JDK verwandt werden, würde eine RuntimeException völlig ausreichen. z.b.
[c]Charset.forName("utf-8");[/c] wirft gleich zwei checked exceptions, obwohl man in 99% der fällen eigentlich genau weiß, dass "utf-8" existiert und auch keine Exception werfen wird.

Um allerdings deine Frage zu beantworten:
ab Java 7 geht das:
Catching Multiple Exception Types and Rethrowing Exceptions with Improved Type Checking

Wenn du nur Java7 zur verfügung hast und wirklcih unterschiedliche exceptions fangen musst, würde ich dir hierzu raten:

try {
// ...
} catch(IOException e) {
    // behandle IO exceptions seperat, falls du sie tatsächlich auflösen kannst. 
} catch(Exception e) {
    throw new RuntimeException("error when trying to do complicated thing that should never ever go wrong", e); 
}

 

[tfa]

Generell gilt als gesichert, dass die Art, wie Java mit Exceptions umgeht nicht ganz optimal ist - bei vielen Exceptions die im JDK verwandt werden, würde eine RuntimeException völlig ausreichen.

Nicht bei vielen, bei allen!