connection à sql et try catch

Salut !

Je suis un peu etonne que tes exemples ne le fassent pas
systematiquement....
En fait tu dois faire qque chose avec cette exception en effet:
1. Soit (et je pense que c'est le cas le + courant), la méthode au niveau
persistence ne sait pas quoi faire en cas d'exception et à ce moment la elle
devrait renvoyer elle-meme l'exception, ce qui veut dire qu'elle sera
traitee à un niveau + haut, par l'affichage d'un message, la sortie brutale
du programme, une tentative de reconnexion, etc....
2. Soit elle sait et effectivement tu dois mettre un bloc try/catch dans ta
methode. Note que pour raisons de lisibilite tu peux n'en mettre qu'un qui
englobera toutes les instructions susceptibles de declencher une exception.

"Yvon Thoraval" <yvon.thoravalNO-SPAM@free.fr> a écrit dans le message news:
1g9chng.1w5mqu21wykkz4N%yvon.thoravalNO-SPAM@free.fr...

je suis qq exemples de connection à une base PostgreSQL et je suis
étonné que javac me demande pour toute méthode appelée du driver :
TestJDBC.java:46: unreported exception java.sql.SQLException; must be
caught or declared to be thrown
boolean more = rs.next();

si bien que cette n'est qu'une suite de try catch, je suis étonné parce
que les exemples trouvés sur le net ne font pas ça systématiquement,
perso j'ai été obligé because javac me ressortait une erreur...

--
yt

jocelyn <elurin@free.fr> wrote:

Je suis un peu etonne que tes exemples ne le fassent pas
systematiquement....

ben oui, je me suis même demandé comment ils étaient arrivés à faire
tourner leur prog parce que chez moi ça ne compilait même pas...

En fait tu dois faire qque chose avec cette exception en effet:
1. Soit (et je pense que c'est le cas le + courant), la méthode au niveau
persistence ne sait pas quoi faire en cas d'exception et à ce moment la elle
devrait renvoyer elle-meme l'exception, ce qui veut dire qu'elle sera
traitee à un niveau + haut, par l'affichage d'un message, la sortie brutale
du programme, une tentative de reconnexion, etc....

oui, c'est ce que je fais les exemples me donnaient :
System.exit(99); (après affichage de l'erreur sur System.err)

2. Soit elle sait et effectivement tu dois mettre un bloc try/catch dans ta
methode. Note que pour raisons de lisibilite tu peux n'en mettre qu'un qui
englobera toutes les instructions susceptibles de declencher une exception.

ça m'intéresse ça, donc je peux faire :

try {
se connecter
lire machin et bidule
se déconnecter
} catch {
afficher l'erreur
}
--
yt

ça m'intéresse ça, donc je peux faire :

try {
se connecter
lire machin et bidule
se déconnecter
} catch {
afficher l'erreur
}

completement c'est meme la bonne facon de faire avec un catch qui ne se
contente pas de logger l'erreurr mais qui s'assure via un bloc ffinally
par exemple de liberer la ressource (connexion SQL)
penses a regarder le spools de connexion 5DBCP par exemple)

Jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941

jerome moliere <jmoliere@nerim.net> wrote:

completement c'est meme la bonne facon de faire avec un catch qui ne se
contente pas de logger l'erreurr mais qui s'assure via un bloc ffinally
par exemple de liberer la ressource (connexion SQL)
penses a regarder le spools de connexion 5DBCP par exemple)

oui oui, j'ai bien mis un bloc finally la structure ressemble à ça :

try {
connection
lire ce qui faut
} catch (ClassNotFoundException e) { pas de pilote dans l'avion...
} catch (SQLException ex) (ex.printStackTrace();
} finally {
try { fermer la connection;
} catch (SQLException ex) (ex.printStackTrace();
}
System.exit(0);

je suppose que le finally {} ne peut pas se mettre dans le try plus haut
(éviterait un autre couple try/catch) ???
--
yt

Yvon Thoraval <yvon.thoravalNO-SPAM@free.fr> wrote:

je suppose que le finally {} ne peut pas se mettre dans le try plus haut
(éviterait un autre couple try/catch) ???

une autre idée qui me semble plus élégante car à quoi bon fermer une
connection si le driver n'a pas été trouvé :

try {
connection
try {
lire ce qu'il faut;
fermer la connection;
} catch (SQLException ex) (ex.printStackTrace();//en attente de
mieux
} catch (ClassNotFoundException e) { pas de pilote dans l'avion...}

pas besoin de bloc finally {} dans ce cas ???
--
yt

Je te propose

try {
connection
lecture/update
etc.
} catch (ClassNotFoundException e) {
est-ce vraiment utile ???
pas de pilote dans l'avion...
} catch (SQLException ex) (
ex.printStackTrace();
} finally {
closeConnection(connection);
}

une méthode static dans la même class ou ailleurs qui s'occupe de fermer les
connections :

static void closeConnection (Connection c) {
try {
c.close();
} catch (SQLException e) {
un log quelque part
throw new RuntimeException(un message, e);
}
}


Comme ça pas d'imbrication de try catch dans le bloc finally.
Et tu récupère l'info quand il y a un problème de fermeture de connection
qui n'est pas une exception mais un problème d'exècution (Runtime)


"Yvon Thoraval" <yvon.thoravalNO-SPAM@free.fr> a écrit dans le message de
news:1g9ckt0.1cva0fv1b449etN%yvon.thoravalNO-SPAM@free.fr...

Yvon Thoraval <yvon.thoravalNO-SPAM@free.fr> wrote:

je suppose que le finally {} ne peut pas se mettre dans le try plus haut
(éviterait un autre couple try/catch) ???

une autre idée qui me semble plus élégante car à quoi bon fermer une
connection si le driver n'a pas été trouvé :

try {
connection
try {
lire ce qu'il faut;
fermer la connection;
} catch (SQLException ex) (ex.printStackTrace();//en attente de
mieux
} catch (ClassNotFoundException e) { pas de pilote dans l'avion...}

pas besoin de bloc finally {} dans ce cas ???
--
yt

cilovie <zorro@club-internet.fr> wrote:

Comme ça pas d'imbrication de try catch dans le bloc finally.
Et tu récupère l'info quand il y a un problème de fermeture de connection
qui n'est pas une exception mais un problème d'exècution (Runtime)

sans doute, je n'ai pas d'expérience là-dessus, j'ai appris très
récemment que le finally n'était exécuté qu'à la fermeture de l'appli.

Dans ce cas il est nécessaire;


--
yt