ubuntuusers.de

HI! Ich habe folgende anweisung in meinem Programmcode:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

try {
	File ausgabeDatei = new File(this.fileName+"_single/" + loopSequence.getName() + ".fasta");
	FileWriter fw = new FileWriter(ausgabeDatei);
	BufferedWriter bw = new BufferedWriter(fw);

	bw.write("%%" + loopSequence.getName() + "\n");
	bw.write(loopSequence.getSequence() + "\n");
	bw.close();
} 
catch (IOException ioe) {
	System.out.println("Habe gefangen: "+ioe);
}

Nun möchte ich allerdings die DataStream im Konstruktor definieren, und die Schreib-Anweisung in einer Methode meiner Klassen.

1) Mache ich dann sowohl für die "Öffnung" des Streams, als auch für das schreiben eine try-catch-Anweisung?

2) Ist diese Anweisung zumindest in einfachen Fällen nur dazu da auf bestimmte Fehler zu reagieren, ggf. je nach Fehler eine eigene Methode aufzurufen?

3) Wie erfahre ich den ob etwas einen Fehler auswerfen kann, und was für einen. In dem Fall würde ich z.B. gerne wissen, ob die entsprechende Datei existiert hat, oder nicht. Aber scheinbar bekomme ich die IOException nur, wenn der Ordner in den ich speichere vorher noch nicht existiert hat, und wenn die datei nicht existiert hat, wird sie einfach erstellt. Aber ist die IOException nur, wenn der Ordner nicht existiert hat? dann benötige ich für die reine Schreib-Anweisung ja kein Exception-Handling mehr.

Grüße!

PS: wie kann ich denn in Java einen Ordner erstellen - (da habe ich noch nicht nach gesucht).

es gibt auch eine FileNotFoundException die ein Kind von der IOException ist und eben genau dann geworfen wird, wenn die Datei nicht gefunden wurde.

Die IOException ist sowieso nur eine ganz generelle Klasse:

Signals that an I/O exception of some sort has occurred. This class is the general class of exceptions produced by failed or interrupted I/O operations.

Wenn du also unterscheiden willst, ob beim Konstruktor oder beim Schreiben der Fehler auftritt, mach das lieber über die entsprechenden Exceptions und nicht über mehrere try-catch-Blöcke..

Desweiteren bildet jeder try-catch auch einen wirklichen Block, das heißt variablen die innerhalb des Blocks definiert werden, sind außerhalb nicht sichtbar :

try {
   String foo = "bar";
 }
catch (IOException ioe) {
  System.out.println("ioe exception");
}

// Hier ist foo nicht mehr sichtbar...

Zu 2: jup, genau.

Zu 3: Entweder aus der API oder aus der IDE, Eclipse zeigt es z.b. an, wenn man etwas schreibt wie:

   File input = new File ("/home/foo/bar");
   BufferedReader bufread = new BufferedReader(new FileReader(input));

zeigt es: Unhandled exception type FileNotFoundException und unterkringelt die Zeile.

Um einen Ordner zu erzeugen:

File newdir = new File("/pfad/zum/neuen/ordner");
newdir.mkDir();

grüße mr_matze

1) ja.

2) jein. Ob auf den Fehler irgendwie reagiert werden kann ist beim Programmieren oft unklar (z.B.: Server in Californien steht in Flammen). Wenn die Routine an der Stelle nicht reagieren kann propagiert man den Fehler an den Aufrufer - vielleicht kann der was machen (anderen Server auswählen? abbrechen?).

3) Es gibt checked und unchecked Exceptions. Aber ich habe jetzt keine Zeit - ich sehe mr_matze hat auch was geschrieben ... ich muß los ...

So wie du das geschrieben hast, wird die Datei nicht geschlossen, wenn eine Exception auftritt. Du musst die close-Methode im finally-Block ausführen. Da close selber Ausnahmen werfen kann, brauchst du einen weiteren try-Block. (Ja, ich weiß, das ist bescheuert, hoffentlich kopiert Sun irgendwann die richtige Vorgehensweise von Microsoft…)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

FileWriter writer = null;
try {
  writer = ...
  ...
} catch(IOException ex) {
  ...
} finally {
  try {
    if(writer != null) writer.close();
  } catch(IOException ex) {
    ...
  }
}

phst schrieb:

So wie du das geschrieben hast, wird die Datei nicht geschlossen, wenn eine Exception auftritt. Du musst die close-Methode im finally-Block ausführen. Da close selber Ausnahmen werfen kann, brauchst du einen weiteren try-Block. (Ja, ich weiß, das ist bescheuert, hoffentlich kopiert Sun irgendwann die richtige Vorgehensweise von Microsoft…)

Ich weiß nicht, was C# bei Ausnahmen im finally-Block macht, aber du willst doch bitte nicht nahelegen, man solle Ausnahmen in finally-Block stillschweigend verschlucken? Das kann nämlich auch prima zu Resourcen-Leaks führen.

@Lunar: Wenn Du nicht weisst was C# "da macht", solltest Du vielleicht nicht so einen Blödsinn annehmen. In C# gibt's ein using-Schlüsselwort, das so ähnlich wie with in Python funktioniert.

Stimmt, daran hatte ich nicht gedacht. Sorry.

Wobei man das Problem des doppelten catch-Blocks doch auch so lösen kann wie in alten Python-Version:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

FileWriter writer = null;
try {
    try {
        writer = new FileWriter("myfile");
        // write something
    } finally {
        if (writer != null)
            writer.close();
    }
} catch (IOException ex) {
    System.err.println(ex.getMessage());
}

Sicherlich nicht eleganter, aber zumindest hat man nur einen catch-Block und so ein einheitlichen Ort zum Behandeln aller möglichen Ausnahmen.

zu 3) Du bemerkst eine checked Exception daran, daß der Kompiler meckert, wenn Du sie weder fängst, noch deklarierst, daß Du sie werfen wirst.

Unterscheiden kannst Du entweder anhand des genauen Typs der Exception:

1
2

catch (FileNotFoundExcpetion fnfe) {/*...*/}
catch (IOExcpetion ioe) {/*...*/}

Umgekehrt klappt es nicht, weil FileNotFoundException eine IOException ist (abgeleitet), und der erste Handler zupackt, der paßt. Teilweise muß man in die Exceptionmeldung reinschauen, um Details zu eruieren.