2011-01-04 12 views
3

Dies ist in Java 6.löschen temporäre Datei während schließlich vs löschen Ausgabedatei beim Fang

ich mehr als einmal gesehen haben, dass die Menschen temporäre Dateien erstellen, tun Sie etwas, benennen Sie es dann in die Ausgabedatei. Alles ist in einen try-finally-Block eingebettet, in dem die temporäre Datei in finally gelöscht wird, falls etwas dazwischen schief geht.

try { 
    //do something with tempFile 
    //do something with tempFile 
    //do something with tempFile 
    tempFile.renameTo(outputFile); 
} 
finally { 
    if (tempFile.exists()) 
     tempFile.delete() 
} 

Ich frage mich, was sind die Vorteile, dass statt etwas zu tun, in die Ausgabedatei direkt und löschen Sie es bei Ausnahmen zu tun.

try { 
    //do something with outputFile 
    //do something with outputFile 
    //do something with outputFile 
} 
catch (Exception e) { 
    if (outputFile.exists()) 
     outputFile.delete(); 
} 

Meine Vermutung ist, dass temporäre Dateien löschen in finally mir zugute kommt, wenn der try-Block viele Arten von Ausnahmen auslösen können. Ist meine Vermutung richtig? Was sonst?

Antwort

7

finally wird immer dann ausgeführt, während die catch oben nicht für Ausnahmen, die von java.lang.Error ableiten ausgeführt wird, und es wird die Datei auch löschen, wenn sie nicht umbenannt werden (dieser Vorgang wirft keine Ausnahme, wenn es nicht ... ein uralter Bug in Java IO).

+1

Darüber hinaus wird der obige Fang auch bei normaler Ausführung nicht ausgeführt (kein Throwable geworfen), während er schließlich in beide Richtungen ausgeführt wird. –

+0

also, wenn ich statt dessen 'Throwable' gewählt habe (obwohl nicht empfohlen) und die Rückgabewerte von' renameTo' überprüft habe. Der Fall ohne "finally" wird dem Fall mit "finally" etwas ähnlicher sein?+1, weil du der Einzige zu sein scheinst, der meine (vage) Frage auf hohem Niveau beantwortet, anstatt mir den Unterschied zwischen "catch" und "finally" beizubringen (was ich sowieso sehr schätze). – Russell

+0

Nein. Sie haben vergessen, dass jemand im Block "try" 'return' aufrufen kann. Sie sehen also, dass die Lösung mit 'finally' * immer * funktioniert, während jede andere Lösung * meistens * funktioniert. –

3

Wenn Sie mit der temporären Datei arbeiten, bis der Vorgang abgeschlossen ist, wird sichergestellt, dass Sie nicht mit einer Ausgabedatei enden, die teilweise geändert wurde.

Zusätzlich wird der finally-Block unabhängig vom Ergebnis ausgeführt, während der catch-Block nur stattfindet, wenn eine Ausnahme auftaucht.

Ein mehr in der Tiefe würde beispielsweise ...

try { 
    //do something with tempFile 

    //operation is complete since we made it this far; transition 
    //tempFile into outputFile 
    tempFile.renameTo(outputFile); 
} 
catch (Exception e) { 
    //perform error logic 
} 
finally { 
    if (tempFile.exists()) 
     tempFile.delete() 
} 
+0

Vielen Dank für Ihren Beitrag, aber auf jeden Fall sollten beide meiner Beispiele nicht zu einer beschädigten führen outputFile', oder? – Russell

+0

@Russell Es hängt davon ab, ob eine Ausgabedatei existiert und überschrieben wird. Wenn dies der Fall wäre, würden Sie die vorhandene Ausgabedatei im zweiten Beispiel entfernen. Wenn keine Datei vorhanden ist, gibt es in Ihrem zweiten Beispiel keine Beschädigung, da Sie die Datei löschen, sollte eine Ausnahme auftreten. –

2

schließlich immer ausgeführt wird, so dass der Unterschied, dass im ersten Fall ist die Datei immer gelöscht wird (sowohl für normale Ausführung und Exception geworfen) . Wenn Sie diese Datei nur löschen möchten, wenn etwas schief gelaufen ist, gehen Sie zum Löschen im catch-Block über.

+0

Danke. Sorry meine Frage war unklar, also lass mich klären. Mein Ziel war es, eine beschädigte 'outputFile' zu ​​verhindern. Ich habe mich gefragt, ob Sie irgendwelche Eingaben zu den beiden Ansätzen gemacht haben, nämlich das Erstellen einer temporären Datei, dann das Umbenennen im Gegensatz zum Erstellen einer Ausgabedatei und das Löschen, wenn Fehler auftreten. – Russell

0

Soweit ich weiß, werden Löschen/Kopieren und andere Dateioperationen über die OS API durchgeführt und es gibt keine Garantie, dass diese APIs im Moment funktionieren. Wenn beispielsweise Ihr eigenes Programm und jedes andere Programm die temporäre Datei geöffnet hält, kann die API die Datei nicht löschen. Im Fall der Arbeit mit TEMP-Datei, wenn dies passiert, wird der Benutzer nicht die schlechte Datei haben, stattdessen eine temporäre Datei haben und er/sie hat keine Ahnung, wofür die Datei ist, aber wenn Sie direkt mit der Hauptdatei arbeiten, Im Falle eines Fehlers beim Löschen der Datei, Ihr Benutzer wird eine Datei, die fehlerhafte Daten enthält, Ich denke,