Vous ne voulez certainement pas trois blocs séparés avec le code tel qu'il est. Dans le premier bloc, vous rencontrez une erreur lors de la configuration writer
, mais dans les blocs suivants, vous êtes en utilisantwriter
, ce qui n'a aucun sens si le premier bloc a échoué. Vous finirez par lancer un NullPointerException
lorsqu'une erreur d'E/S se produit — n'est pas idéal. :-)
Il y a beaucoup de place pour le style dans ce genre de choses, mais voici une réinterprétation assez standard de votre fonction. Il utilise seulement deux blocs (bien que vous pouvez choisir de rajouter un troisième, voir les commentaires dans le code):
public void save(Object object, File file) {
BufferedWriter writter = null;
try {
writter = new BufferedWriter(new FileWriter(file));
Dictionary dictionary = (Dictionary)object;
ArrayList<Card> cardList = dictionary.getCardList();
for (Card card: cardList) {
String line = card.getForeignWord() + "/" + card.getNativeWord();
writter.write(line); // <== I removed the block around this, on
// the assumption that if writing one card fails,
// you want the whole operation to fail. If you
// just want to ignore it, you would put back
// the block.
}
writter.flush(); // <== This is unnecessary, `close` will flush
writter.close();
writter = null; // <== null `writter` when done with it, as a flag
} catch (IOException e) {
e.printStackTrace(); // <== Usually want to do something more useful with this
} finally {
// Handle the case where something failed that you *didn't* catch
if (writter != null) {
try {
writter.close();
writter = null;
} catch (Exception e2) {
}
}
}
}
Note sur le bloc finally
: Ici, vous pouvez manutentionneront le cas normal (dans ce cas, writter
sera null
), ou vous pourriez gérer une exception que vous n'avez pas détectée (ce qui n'est pas inhabituel, l'un des principaux points d'exceptions est de gérer ce qui est approprié à ce niveau et de passer toute autre chose à l'appelant) . Si writter
est !null
, fermez-le. Et quand vous le fermez, manger toute exception qui se produit ou vous obscurcir l'original. (J'ai des fonctions utilitaires pour fermer des choses tout en mangeant une exception, pour exactement cette situation.Pour moi, cela pourrait être writter = Utils.silentClose(writter);
[silentClose
retourne toujours null
]). Maintenant, dans ce code, vous ne pouvez pas vous attendre à d'autres exceptions, mais A) Vous pouvez changer cela plus tard, et B) RuntimeException
s peut se produire à tout moment. Il vaut mieux s'habituer à utiliser le motif.
Merci pour une si bonne explication. – Eugene
@AndroidNoob: Pas de soucis! Content que cela ait aidé. –
@ T.J. Crowder pourquoi fermez-vous 'writer' dans le bloc' try'? N'est-ce pas redondant? –