Je me demande si je suis en train de faire n'imp' ou pas.
Qqn pourra sans doute m'aiguiller.
J'utilise un pool de connections JDBC implémenté entant que driver JDBC.
Celui-ci impose néamoins une contrainte supplémentaire par rapport aux drivers JDBC habituels : il nécessite que soient fermés impérativement tous les ResultSet, Statement, et Connection.
Donc, après avoir "ouvert" une instance de chacune de ces 3 classes, la doc proconisait de procèder comme suit :

 
Vous aurez compris ce que sont "r", "stmt", et "c", pas vrai ?
Cette méthode n'est pas terrible, puisqu'on perd la trace des exceptions éventuellement lancées. Je voudrais que ma méthode transmette ces éventuelles exceptions.  
J'ai fait un truc étrange, je me demande le comportement que ça peut avoir. Voici :

 
Qqn à une idée ?

hum, dans tous les cas quoi qu il arrive tu feras donc un m_connection.close();
donc je vois pas trop lutilite de faire un try sans catch nested.
 
maintenant j ai ptet rien compris

J'ai rien compris
Stu veux transmettre tes exceptions, ba i suffit que ta méthode ait une clause throws dans sa signature, du style public int maMethode(char youpi) throws SQLException
et pis tout ce qui appellera maMethode() pourra catcher les SQLException

moi j'ai compris ta question, et il me semble quoi oui : la seule solution est d'imbriquer les finnaly. D'un point de vue purement java en tout cas.
 
maintenant, je me suis toujours demandé si la fermetuer de la connection ne fermait pas aussi tous les trucs qui avaient été ouvert à travers elle ...
 
PS : Ce qu'il veut c'est être sûr de fermer sa connection, même si la fermeture du statement plante

Normalement, lorsque l'on ferme un Statement il ferme également les ResultSet associés. Donc tu peut te passer de fermer le ResultSet.
Je crois que la meilleure solution est effectivement de mettre tes close() dans des clauses finally et de laisser remonter les SQLExceptions comme l'a dis Taiche.

j'ai peut êter pas si bien compris la question que ca finalement

Si si Benou, t'as parfaitement compris.

 
Moi aussi je m'demande ça. Mais quand même, la doc de mon pool précise qu'il est important de tout fermer. Alors j'applique, bêtement...

c'est aussi ce que j'ai toujours fait par sécurité ..

Et je me demande un truc : dans le code que j'ai donné au 1er post, avec tous les finally, si chacune des 3 fermeture lance une exception, au final, elle va transmettre laquelle ma mathode ?

 
Ce qui veut dire que t'es forcé de faire un code ressemblant à mon bloc crado de finally ?
Vu que ça semble être le seul moyen d'être sur de faire toutes les fermetures.

 
Ben non. Comme Benou l'as précisé :
Si je fais simplement comme tu dis, si la 1ère fermeture (celle du ResultSet) lance une exception, on sort de la méthode, l'exception est transmise, mais ni le Statement, ni la Connection ne sont fermés.

ouais ... enfin tu fais une méthode utilitaire close(ResultSet, PreparedStatement, Connection)  qui fait tout ca comme il faut ...

Ouais non mais t'es marrant mais mon post c'était la 2ème réponse et je précisais bien que j'avais pas pigé ta question

 
Une méthode close qui contient le bout de code que j'ai posté, bien sur. C'est déja le cas. Je trouve ça pas bien beau comme code en tt cas. Tant pis pour l'esthétique de la méthode .

 
Transmettre les exceptions, j'y arrive à peu près, merci !  
 
PS : c'est vrai que comme mon post est pas tourné de manière hyper claire, désolé.

Ba t'sais, vu le nombre de mecs qui se pointent sans connaître le classpath, maintenant j'me méfie

si j'étais toi je rajouterait quelques if (leTruc != null) pour éviter les NullPointerException

 
ha, c'était déja fait depuis que j'ai posté. Merci.
Et pour la question que j'ai posée, t'as une idée ?

 
Je poste pas super souvent, mais j'pensais que tu connaissais mon pseudo qd même.
(faut pas être nerveux comme ça...)

il me semble que les premières exceptions sont perdus et que seule la dernière est lancée. A vérifier ...

J't'avouerais que j'ai pas fait gaffe

 
rapport avec les p'tits bonshommes tout rouges à la fin de tes posts.

 
Finalement, si les 1ères sont perdues, je peux aussi bien faire la 1ère méthode que j'évoquait (celle préconisée par la doc de mon API de pools), ça revient au même...

Ah ouais mais non Quand chu pas content, c'est ou ; le n'a pas grande signification en lui-même et c'est pour ça que j'le mets souvent

Haaaaaaannnnnn, d'accord !
C'est noté.

ben non : avec la méthode dont tu parles tu perds toutes les exceptions ! en imbriquant les blocs finally tu ne perds les premières exceptions que si une autre est générée (de toute façon, tu ne peux pas throwser plusieurs exceptions ...).

Ha oui, t'as raison, j'suis bête !
(Je m'en doute que je n'peux lancer qu'une seule exception).
 
Merci beaucoup en tout cas.

Au fait, juste une question :
si je ferme une connexion, sans fermer préalablement le(s) Statement et ResultSet qui y sont attaché(s), ça les ferme aussi, non ?

 
spec JDBC 3.0 chapitre 3.1.3 "closing statement Objects" page 96. Copié avec un outil qui chie.

 
Perso j'ai fait des méthodes de ce type là pour ma part afin de lancer les close de mes Statement et Connection
 
et je les appelle comme ça :
 

 
Edit : bon faut dire en plus que j'ai pas nécessairement besoin que la fermeture se passe bien globalement mais sinon les finally imbriqués ça me semble pas si mal
 
Bonhomme

Outil qui chie sacrément, ouais.
En gros, on est pas obligé de les fermer, mais c'est conseillé. Je demandais ça à cause du pool de connexion dont je parlais au tout début de ce thread. Il ne devait pas implémenter correctement cette spec, parce qu'il demandaient dans la doc de bien TOUT fermer obligatoirement. Merci.

 
Pb de ta méthode : la connexion peut ne pas être fermée, sans que tu catch quoi que ce soit dans ton bloc principal. (même si tu enregistre ça dans ton log)

hého bonhomme, on en a déjà débatu au début de blablatech@java, je crois que 2 grandes méthodes méthodes étaient dégagés (dont la tienne en plus propre).

 
ouh là là les thread strop long j'ai du mal à les lire, c'est qu'il parait que des fois j'ai du boulot
 
Sinon effectivement la mienne c'est pas hyper propre mais bon quand on a pas le temps on se contente ce que l'on peut    
 
Bonhomme