Une question de style

Comme l'évoquait Rémi, le bloc try/(catch/)finally impose la
déclaration à l'avance.

Connection conn = null;
try {
conn = myConnectinPool.getConnection();
//...
} finally {
try { conn.close(); } catch (Exception e) {}
}

moi je testerais la nullité avant la destruction et je garderai le catch
pour autre chose que le finally (cépabo d'empiler les try-catch je
trouve, qd on peut l'éviter)

ok pour le test à null mais si tu ne veux pas que l'exception du close soit remontée au niveau
supérieur, y'a pas le choix.

Connection conn = null;
try {
conn = myConnectinPool.getConnection();
//...
} catch (Exception e){
//...
} finally {
if (conn != null) conn.close();
}

et l'exception levée par le close ?

Le choix de Derek me semble meilleur : il laisse passer les exceptions mais s'assure avant de bien
fermer la connexion qu'il a éventuellement ouverte (effectivement il manquait le test à null).
Ton code est bizarre dans le sens ou il 'catch' les exceptions mais peut en lever une si le close
plante. C'est pas très logique.

Sébastien

(...)

Connection conn = null;
try {
conn = myConnectinPool.getConnection();
//...
} catch (Exception e){
//...
} finally {
if (conn != null) conn.close();
}

et l'exception levée par le close ?

Le choix de Derek me semble meilleur : il laisse passer les exceptions
mais s'assure avant de bien fermer la connexion qu'il a éventuellement
ouverte (effectivement il manquait le test à null).
Ton code est bizarre dans le sens ou il 'catch' les exceptions mais peut
en lever une si le close plante. C'est pas très logique.

Sébastien

C'est pire que pas très logique: cela fait que l'exception dans le
finally est remontée *à la place* de l'exception dans le try, donc on
perd de l'information. Il faut le double catch.

(...)

Connection conn = null;
try {
conn = myConnectinPool.getConnection();
//...
} finally {
try { conn.close(); } catch (Exception e) {}
}

moi je testerais la nullité avant la destruction et je garderai le catch
pour autre chose que le finally (cépabo d'empiler les try-catch je
trouve, qd on peut l'éviter)

(...)

Le double catch n'est pas évitable (cf. le reste du thread), et par
suite puisqu'il y a un deuxième catch, il saura bien attraper aussi
NullPointerException donc le test à null ne sert à rien. Et inutile de
parler d'optimisation, l'optimisation se fait dans les 20% du code où on
passe 80% du temps, et le traitement des exception n'en fait pas partie.
Maintenant, intellectuellement, tester le null est plus satisfaisant,
c'est juste que ça fait plus de code à écrire, puis plus de code à
comprendre et à maintenir. Et aussi, je suis très fainéant (sinon je
ferai un truc sérieux plutôt que du java, construire des maisons,
fabriquer des voiture, cuire du pain, je ne sais pas un truc utile de
courageux, pas de l'informatique).

Juste pour enfoncer le clou sur le double catch, souvent on a plusieurs
ressources à libérer, exemple:
Connection conn = null;
Statement stmt = null;
try {
conn = myConnectinPool.getConnection();
stmt = //...
//...
} finally {
try { stmt.close(); } catch (Exception e) {}
try { conn.close(); } catch (Exception e) {}
}

Sans le catch après stmt.close() en cas d'échec de fermeture du statment
on ne libère pas la connexion.

a+