Questions sur les exceptions et finally

Bonjour à tous,

Code:

---

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

public int loadCounter(String filename) { FileReader reader = null; int counter; try { reader = new FileReader(filename); ... return counter; } catch(FileNotFoundException e) { throw new NotFoudnException("File " + filename, e); } finally { if( reader != null ) reader.close(); } }

---

est-il vraiment nécessaire de mettre les instructions "if( reader != null ) reader.close();" dans un bloc finally ?
si j'ai bien compris si une exception est levée dans le try, alors on execute les instructions du catch correspondant à l'exception, puis les instructions suivantes sont executées.

Je pense donc qu'ici le finally est obligatoire à cause du throw, ai-je raison ?

merci à vous

autre organisation possible : double try

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public int loadCounter(String filename) { FileReader reader = null; int counter; try { reader = new FileReader(filename); try { ... /// code qui exploite reader return counter ; } finally { reader.close(); } } catch(IOException e) { /// }   }

---

Le finally est effectivement obligatoire à cause du throw, mais aussi à la fin de ton try tu fais un "return".
Donc si tu retires le finally et s'il n'y a pas d'exception, tu va aller jusqu'au bout de ton try, puis arrêter ta méthode, et ne passera donc pas dans ton reader.close();

Citation:

---

Envoyé par Jidefix

Le finally est effectivement obligatoire à cause du throw, mais aussi à la fin de ton try tu fais un "return".
Donc si tu retires le finally et s'il n'y a pas d'exception, tu va aller jusqu'au bout de ton try, puis arrêter ta méthode, et ne passera donc pas dans ton reader.close();

---

ok merci.

Et dans ce code là :

Code:

---

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

public int loadCounter(String filename) { FileReader reader = null; int counter;   try { reader = new FileReader(filename); ... } catch(FileNotFoundException e) { // Renvoyer l'exception dans une exception implicite throw TechnicalException.rethrow("Cannot open counter file " + filename, e); } finally { if( reader != null ) reader.close(); } return counter;

---

le "return counter;" ne sera pas execute à cause du throw dans le catch ?
mais s'il n'y avait pas eu de throw dans le catch, "return counter;" aurait été alors executé (après les instructions du catch et du finally) ?
ai-je bien compris ?

Citation:

---

Envoyé par _LittleFlea_

le "return counter;" ne sera pas execute à cause du throw dans le catch ?
mais s'il n'y avait pas eu de throw dans le catch, "return counter;" aurait été alors executé (après les instructions du catch et du finally) ?
ai-je bien compris ?

---

1)oui puisque ta fonction va planter au niveau du rethrow qui n'est pas catché => la fonction exécute le/les éventuel(s) finally puis se termine avec l'exception

2)oui puisque l'exception aurait été catchée, tu serais sorti sans encombre du catch, aurait exécuté le finally, puis serait ensuite passé sur le return.

3)visiblement oui ;)

oui


en pratique, ce genre de code sensible (libérer les ressources système) sont mise systématiquement dans un bloc finally pour plusieurs raison

-> le bloc est garanti d'être exécuté (pas nécessairement dans son entièreté, ca dépend du contenu)
-> il est plus facile de mettre ça dans une bloc finally que de calculer le code principal pour etre sur que c'est toujours exécuté (un programmeur, c'est fainéant pas nature)
-> Il est possible que des exceptions runtime non prévues par le codeur remontent (nullpointerexception dans un traitement, unsupportedoperation ou autres)

Merci à tous pour vos réponses.

Et si j'ai un programme de ce style :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

try{ quelquechose = open(..);   try{} catch(Exception e){ throw e; }   } catch{} finally{quelquechose.close();}

---

quelquechose.close() sera-t'il executé si e est levée ?

oui, dès que tu rentre dans un try, tu a la garantie de rentrer dans le bloc finally associé (dans les limites du bon fonctionnement de la jvm, un crash jmv restera un crash jvm :p)

sauf que quelquechose.close() peut:
- déclencher une NullPointerException si tu n'as pas pu faire ton open
- déclencher une IOException
donc ta disposition de bloc ne va pas!

le pattern

Code:

---

1 2 3 4 5 6 7 8 9 10 11

try { objet = creationObjet() ; try { // faire des choses avec objet } finally { // fermeture } } catch(MesExceptions exc){ // au rapport }

---

ne te convient pas?

Salut,


Tout à fait d'accord avec professeur shadoko. Le try/catch/finally se révèle plus complexe à utiliser et source d'erreur potentielle (gestion des NPE, etc). Le code du finally doit vraiment contenir le moins de code possible car cela peut cacher une valeur de retour ou une exception précédemment levé...


Le try/finally et une initialisation en ligne se révèle plus adapté :

Code:

---

1 2 3 4 5 6

Ressource res = new Ressource(); try { // Utilisation de res à l'intérieur du try/finally } finally { res.close(); }

---

:arrow: On ne rentre dans le try QUE si la ressource a bien été créé, et dans ce cas elle sera correctement libérée par le finally sans risque de NullPointerException.

Cela permet de laisser remonter les exceptions, mais surtout si besoin de les traiter toutes au même niveau via un try/catch imbriqué :

Code:

---

1 2 3 4 5 6 7 8 9 10

try { Ressource res = new Ressource(); try { // Utilisation de res à l'intérieur du try/finally } finally { res.close(); } } catch (IOException e) { // Traitement des exceptions }

---

Alors qu'avec un try/catch/finally il te faut gérer d'une manière particulière l'exception de la méthode close() (ce qui était d'ailleurs ... :?



Cette solution a toutefois un défaut, mais qui se révèle relativement rare, dans le cas de figure suivant :

1. Une exception survient lors du traitement.
2. On est renvoyé vers le finally qui exécutera le close()
3. Ce dernier provoque une nouvelle exception qui va caché la précédente.

:arrow: On se retrouve alors uniquement avec l'exception du close(), alors que l'exception originale a été perdue...


Toutefois ce cas de figure est vraiment très rare...



a++

Citation:

---

Envoyé par adiGuba

Ce dernier provoque une nouvelle exception qui va caché la précédente.
On se retrouve alors uniquement avec l'exception du close(), alors que l'exception originale a été perdue...


Toutefois ce cas de figure est vraiment très rare...



a++

---

rare oui et surtout, de toutes façons, les autres formes d'imbrication ont elle aussi des problème similaire. Dès qu'on travaille sur un finally, on cours le risque de cacher une exception avec une autre (d'où l'intérêt de garder ces bloc les plus court et simple possible).

Mais pour en revenir à la question d'origine, je crois que l'auteur essaie juste de comprendre comment marchent les bloc try/catch/finally exactement ;)