try finally w.r.t System.exit

Bonjour,

Dans mon esprit, un bloc finally était toujours exécuté. L'exemple suivant me fait douter...

Code:

---

1 2 3 4 5 6

try { System.exit(0); } finally { System.out.print("hello"); }

---

.


Ma question est donc où et comment faire l'appel à exit quand il y a du boulot à faire à la fermeture du programme (typiquement des close sur des canaux)?

Merci

AMHA, le

Code:

---

System.exit(0);

---

est à proscrire.

Pour la simple et bonne raison que si tu as bien géré tes exceptions, tu peux quitter ton traitement proprement, en ayant tout bien fermé tes ressources, loggué l'erreur pour permettre de comprendre où et quand ton traitement à planté, etc...

En général, la bonne pratique veut que tu fasses quelque chose du genre:

Code:

---

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

try{ //tu ouvres tes ressources   } catch(tonException1 e){ // logguer // mettre un flag pour dire que ça à planté // ... } finally{ // fermer les ressources qui nécessitent d'être fermées }

---

Citation:

---

Envoyé par LGnord

Bonjour,

Dans mon esprit, un bloc finally était toujours exécuté.

---

Ha non, il est toujours exécuté à la sortie d'une bloc try/catch. en l'occurence ici, tu est dans un des trois cas(enfin je n'en connait que trois) où l'on ne sort jamais du bloc try

-> Si on sort de la jvm avec un System .exit -> le finally n'est pas exécuté, on arrive jamais jusque là
-> Si le code à l'intérieur du try / catch n'ent fini jamais de s'exécuter
-> Si la jvm crashe

Citation:

---

Ma question est donc où et comment faire l'appel à exit quand il y a du boulot à faire à la fermeture du programme (typiquement des close sur des canaux)?

---

Le plus propre: plus haut dans la pile. Par exemple en remontant une exception custom de type ApplicationShutdown.

Code:

---

1 2 3 4 5 6 7

public static void main(String[] args){ try { // ton code applicatif } catch (ApplicationShutdownException e){ System.exit(e.getExitCode()); } }

---

Ceci dit, la fermeture des canaux n'est en général pas trop un soucis si tu veux sortir de ton application: tous les handles possédés par ton application vont être fermé par l'OS lors de ton exit ;)

Le System.exit dans le code, a quand même un gros incovénient: les unit tests sont ch*** à écrire après :)

Salut,

Citation:

---

Envoyé par Carhiboux

En général, la bonne pratique veut que tu fasses quelque chose du genre:

Code:

---

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

try{ //tu ouvres tes ressources   } catch(tonException1 e){ // logguer // mettre un flag pour dire que ça à planté // ... } finally{ // fermer les ressources qui nécessitent d'être fermées }

---

---

Perso je conseillerais plutôt le pattern suivant, pour chaque ressource :

Code:

---

1 2 3 4 5 6

// Ouverture de la ressource try { // Traitement sur la ressource } finally { // Libération de la ressource }

---

Le tout entouré d'un bloc try/catch si l'on souhaite traité les exceptions.

Ou le try-with-ressource de Java 7 bien sûr (qui se base sur ce pattern)

Citation:

---

Envoyé par tchize_

Le System.exit dans le code, a quand même un gros incovénient: les unit tests sont ch*** à écrire après :)

---

Ca peut même être très dangereux lorsque ca traine dans une librairie utilisé dans une application serveur... :aie:


a++

Citation:

---

Envoyé par adiGuba

Ca peut même être très dangereux lorsque ca traine dans une librairie utilisé dans une application serveur... :aie:

---

Moyennement dangereux, la spec J2EE dit que le serveur doit refuser les appels à System.exit (typiquement via le securitymanager)

@tchize_ : j'ai déjà vu des serveurs J2EE s'arrêter à cause de cela ;)
(remarque : ils ne respectaient peut-être pas les specs)

Mais sinon plus globalement "application serveur" ne signifie pas obligatoirement "J2EE" (même si c'est probablement le plus courant).


a++

De fait ^^

J'ai personellement vu une libriarie faire un System.out.close(). C'est très drôle aussi dans un serveur. On a mis des jours comprendre pourquoi le serveur arrêtait abrutement de donner des message dans le log :mouarf: