Est-il une préférence pour les sous blocs try/catch?

J'ai peur il y a un gros problème avec le premier exemple, qui est que si une exception se produit après la lecture, le finally bloc s'exécute. So far So good. Mais que faire si le fr.close() provoque alors une autre exception à être jetés? Ce sera "trump" la première exception (un peu comme mettre return dans un finally bloc) et vous perdrez toutes les informations au sujet de ce qui s'est réellement à l'origine du problème pour commencer.

Votre bloc finally doit utiliser:

IOUtil.closeSilently(fr);

où cette méthode utilitaire ne fonctionne tout simplement:

public static void closeSilently(Closeable c) {
    try { c.close(); } catch (Exception e) {} 
} 

Si les deux lire et près lancer une exception, l'exception de lire sera caché dans l'option 1. Donc, la deuxième option n'est plus d'erreur de manipulation.

Cependant, dans la plupart des cas, la première option sera toujours préféré.

1. Dans de nombreux cas, vous ne pouvez pas gérer les exceptions dans la méthode qu'ils ont généré, mais vous devez toujours encapsuler le flux de manutention à l'intérieur de cette opération.
2. Essayez d'ajouter un écrivain pour le code et de voir comment verbose la deuxième approche se.

Si vous avez besoin de passer tous les générées exceptions, il peut être fait.

J'ai l'habitude de faire ce qui suit. Tout d'abord, de définir un modèle de la méthode en fonction de la classe de traiter avec le try/catch mess

import java.io.Closeable;
import java.io.IOException;
import java.util.LinkedList;
import java.util.List;
public abstract class AutoFileCloser {
private static final Closeable NEW_FILE = new Closeable() {
public void close() throws IOException {
//do nothing
}
};
//the core action code that the implementer wants to run
protected abstract void doWork() throws Throwable;
//track a list of closeable thingies to close when finished
private List<Closeable> closeables_ = new LinkedList<Closeable>();
//mark a new file
protected void newFile() {
closeables_.add(0, NEW_FILE);
}
//give the implementer a way to track things to close
//assumes this is called in order for nested closeables,
//inner-most to outer-most
protected void watch(Closeable closeable) {
closeables_.add(0, closeable);
}
public AutoFileCloser() {
//a variable to track a "meaningful" exception, in case
//a close() throws an exception
Throwable pending = null;
try {
doWork(); //do the real work
} catch (Throwable throwable) {
pending = throwable;
} finally {
//close the watched streams
boolean skip = false;
for (Closeable closeable : closeables_) {
if (closeable == NEW_FILE) {
skip = false;
} else  if (!skip && closeable != null) {
try {
closeable.close();
//don't try to re-close nested closeables
skip = true;
} catch (Throwable throwable) {
if (pending == null) {
pending = throwable;
}
}
}
}
//if we had a pending exception, rethrow it
//this is necessary b/c the close can throw an
//exception, which would remove the pending
//status of any exception thrown in the try block
if (pending != null) {
if (pending instanceof RuntimeException) {
throw (RuntimeException) pending;
} else {
throw new RuntimeException(pending);
}
}
}
}
}

Note le "en attente" exception -- cela prend en charge les cas où une exception levée lors de proximité serait masque une exception, nous pourrions vraiment se soucier.

Enfin essaie de fermer de l'extérieur de toute décorée de flux en premier, donc si vous aviez un BufferedWriter l'enveloppant d'un FileWriter, nous essayons de fermer la BuffereredWriter premier, et si cela échoue, essayez de fermer le FileWriter lui-même.

Vous pouvez utiliser la classe ci-dessus comme suit:

try {
//...
new AutoFileCloser() {
@Override protected void doWork() throws Throwable {
//declare variables for the readers and "watch" them
FileReader fileReader = null;
BufferedReader bufferedReader = null;
watch(fileReader = new FileReader("somefile"));
watch(bufferedReader = new BufferedReader(fileReader));
//... do something with bufferedReader
//if you need more than one reader or writer
newFile(); //puts a flag in the 
FileWriter fileWriter = null;
BufferedWriter bufferedWriter = null;
watch(fileWriter = new FileWriter("someOtherFile"));
watch(bufferedWriter = new BufferedWriter(fileWriter));
//... do something with bufferedWriter
}
};
//.. other logic, maybe more AutoFileClosers
} catch (RuntimeException e) {
//report or log the exception
}

En utilisant cette approche, vous n'avez jamais à vous soucier de le try/catch/finally pour faire face à la fermeture des fichiers à nouveau.

Si c'est trop lourd pour votre utilisation, à moins penser à la suite de la try/catch et le "en attente" approche de la variable qu'il utilise.

2ème approche.

Sinon, je ne vois pas de vous attraper l'exception de la FileReader constructeur

http://java.sun.com/j2se/1.5.0/docs/api/java/io/FileReader.html#FileReader(java.lang.Chaîne de caractères)

public FileReader(String fileName)
throws FileNotFoundException

Donc, j'ai l'habitude le constructeur à l'intérieur du bloc try ainsi. le bloc finally vérifie si le lecteur n'est PAS null avant d'essayer de faire un close.

Le même schéma va pour la source de données, de Connexion, de Déclaration, ResultSet.

J'aime l'approche par @Chris Marshall, mais je n'ai jamais aime voir les exceptions se avalé en silence. Je pense qu'il est préférable d'enregistrer des exceptions, surtout si vous êtes contiuing indépendamment.

J'ai toujours utiliser une classe utilitaire pour gérer ce genre de commune des exceptions, mais je ferais ce petit différent à sa réponse.

Je serais toujours utiliser un enregistreur (log4j pour moi) pour le journal des erreurs, etc.

IOUtil.close(fr);

Une légère modification à la méthode d'utilitaire:

public static void close(Closeable c) {
try {
c.close();
} catch (Exception e) {
logger.error("An error occurred while closing. Continuing regardless", e); 
} 
}