| nraynaud |
R3g a écrit :
C'est quoi exactement le problème là pour toi ? Parce que moi je vois surtout que rs est encore null dans le finally, et qu'il catche les même exceptions et fait le même traitement dans les deux catch.
Maintenant vu qu'il est toujours recommandé de fermer ce qui a été ouvert, moi dans le finally je mets des trucs genre
Code :
- finally {
- try{ rs.close(); } catch.....
- try{ ps.close(); } catch.....
- try{ c.close(); } catch....
- }
|
Mais quelque chose me dit que c'est pas ça que tu voulais dire par "faire correctement les try/finally".
|
heu le rs, c'est de ma faute, étourderie.
quand on ouvre des ressources récursivement, c'est la misère, il faut emboiter les try/catch, sinon il seront pas refermés corectement à la sortie. Sauf que la règle habituelle veut que si l'ouverture a foiré, on le ferme pas (logique).
je déplace le vrai try/catch, pour simplifier :
Code :
- public void store(CustomerBean ejb) throws EJBException {
- try {
- Connection c = jdbcFactory.getConnection();
- try {
- PreparedStatement ps = c
- .prepareStatement("update customer set userid=?, firstname=?,"
- + " latsname=?,address=?, phone=?, shareholder_stat=? "
- + "where customerid=?" );
- try {
- ps.setString(1, ejb.getUserID());
- ps.setString(2, ejb.getFirstName());
- ps.setString(3, ejb.getLastName());
- ps.setString(4, ejb.getAddress());
- ps.setString(5, ejb.getPhone());
- ps.setString(6, ejb.getShareholderStatus());
- ps.setString(7, ejb.getCustomerID());
- ps.executeUpdate();
- } finally {
- ps.close();
- }
- } finally {
- c.close();
- }
- } catch (SQLException e) {
- e.printStackTrace();
- }
- }
|
ce qui est quand même un beau bordel.
évidement, il faut remonter la SQLException, mais j'ai pas encore étudié comment il faut la wrapper dans l'EJBException (et je vais pas le faire tout-de-suite. |
