JDBC - Fermeture des composants

Version imprimable

Bonjour à tous,

Je poste ici après avoir eu un débat avec les collègues concernant la fermeture de composants JDBC.

La méthode est la suivante :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // Déclaration des componsants JDBC Connection conn = null; PreparedStatement stmt = null; ResultSet rs = null; try{ // Ouverure et utilisation des componsants JDBC ... } // A noter : pas de bloc catch, les exceptions seront remontées au niveau suppérieur finally{ try{rs.close();}catch(Exception e){} try{stmt.close();}catch(Exception e){} try{conn.close();}catch(Exception e){} }
Les critiques remontées sont les suivantes :
1- On catch une exception générique et non un sous type SQLException
2- On ne log pas l'exception

Mon avis : si une exception à lieu durant la fermeture des composants, c'est qu'en principe une exception a déja été levée dans le try{} et donc elle sera catchée au niveau supérieur. La logger ne sert donc à rien. Et de toute façon si le close() plante et que la connexion a été fermée (ex:coupure réseau) avant l'entrée dans le bloc finally, de toute façon le commit a déja eu lieu et cela ne pose aucun problème.

Qu'en pensez-vous ? Comment avez-vous l'habitude de procéder pour fermer vos composants JDBC ? Est-ce que vous trouvez cette méthode "propre" ou pas ?

Bonjour,

J'utilise le même principe que toi mais je me sers de la librairie commons apache IO qui propose une méthode pour fermer une ressource silencieusement :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/**
     * Unconditionally close a <code>Closeable</code>.
     * <p>
     * Equivalent to {@link Closeable#close()}, except any exceptions will be ignored.
     * This is typically used in finally blocks.
     * <p>
     * Example code:
     * <pre>
     *   Closeable closeable = null;
     *   try {
     *       closeable = new FileReader("foo.txt");
     *       // process closeable
     *       closeable.close();
     *   } catch (Exception e) {
     *       // error handling
     *   } finally {
     *       IOUtils.closeQuietly(closeable);
     *   }
     * </pre>
     *
     * @param closeable the object to close, may be null or already closed
     * @since Commons IO 2.0
     */
    public static void closeQuietly(Closeable closeable) {
        try {
            if (closeable != null) {
                closeable.close();
            }
        } catch (IOException ioe) {
            // ignore
        }
    }

Elle n'effectue le close() que si le closeable n'est pas null (chose que tu ne fais pas et qui pourrait provoquer une NullPointerException qui sera catchée par ton "catch(Exception e)").

Sinon je trouve que ton raisonnement est le bon, ça n'a pas grand intérêt de logger une exception sur la fermeture d'une ressource, c'est bien pour cela qu'apache a fait une méthode utilitaire...

Romain.

18/02/2013, 10h30
fr1man

Ce que je fais :
Ajouter une clause throws SQLException sur ma méthode.
Ensuite dans le finally, je ne catche pas les exceptions du close, je les laisse remonter à l'appelant.

Pour les remarques, je suis d'accord d'éviter de catcher les exceptions generiques (dans ce cas précis), et puis d'éviter les catchs vides.
Puisque je laisse remonter l'exception, je ne vois pas d'interet de rajouter un log.

Comme cela a été ajouté, je teste aussi la nullité de mes objet avant d'appeler le close.
18/02/2013, 10h38
romano62880

Merci pour vos réponses.

Pour rg77140, je ne connaissais pas la fonction utilitaire d'Apache, merci pour l'info. En général je procéde d'une façon similaire en créant une méthode statique JDBCCloser.close(ResultSet rs, Statement st, Connection conn) qui se charge de la fermeture des composants s'ils sont non null.

fr1man, la je ne suis pas d'accord concernant cette méthode. Car si une exception est levée dans le finally sur le close, alors cette exception va écraser une éventuelle exception levée dans le try, et donc l'exception initiale, celle qui nous interesse, est perdue.
De même si tu ne fais pas un try/catch pour chaque objet à fermer, il est possible que le close() sur le premier objet plante, et donc les close() suivants ne seront pas appelés.
18/02/2013, 10h55
fr1man

Citation:

Car si une exception est levée dans le finally sur le close, alors cette exception va écraser une éventuelle exception levée dans le try, et donc l'exception initiale, celle qui nous interesse, est perdue.

Je ne vois pas pourquoi elle serait perdue si on la laisse remonter.

Pour le coup des catchs que je ne fais pas dans le finally, tu n'a pas tort, mais ta technique n'est pas mieux, car si un problème intervient uniquement sur le close, et bien tu n'auras aucune trace.
18/02/2013, 11h09
romano62880
Essaye de faire un :
Code:

1 2 3 4 5 6 try{ throw new Exception("Exception qu'on veut catcher"); } finally{ throw new Exception("Exception sur le close"); }
Et tu verras que c'est "Exception sur le close" qui va être propagée. L'exception lancée dans le try est tout simplement perdue !!! Alors que c'est elle qui contient le message d'erreur réel.

Si un problème intervient sur le close comme tu dis, pour moi on s'en fou complétement. Ca n'a strictement aucun impact et ne nécessite pas pour moi d'être loggé. Au niveau du finally, le commit() a déja été réalisée, ou une exception levée. Si la connexion a été perdue entre temps... aucun impact.
18/02/2013, 11h11
rg77140
J'ai oublié de te demander quelle version de JAVA tu utilises ? Car en JAVA 7 il y a une nouvelle méthode pour clôturer les ressources, je te laisse lire : http://docs.oracle.com/javase/tutori...urceClose.html

En gros en java 7 le try a une section avec des parenthèses qu'il n'avait pas avant :
Code:

1 2 3 4 5 6 try( /* déclaration des ressources */ ){ // utilisation des ressources } catch(IOException e){ // gestion exception } // en sortie du try les ressources sont closes quoi qu'il arrive
Romain.

EDIT : Je t'ai parlé avant de IO Utils, mais pour des ressources JDBC, c'est plutôt DB Utils qu'il faut utiliser : http://commons.apache.org/dbutils/
18/02/2013, 11h16
romano62880

Merci pour l'info, j'étais en effet déja au courant pour Java 7.
Hélas on est toujours sur java 6 sur le projet :(