É verdade, felipe, tem toda a razão. Na verdade eu não faço assim, tenho uma
classe pronta que extende Connection e trata essas coisinhas pra evitar
que o codigo fique muito poluido. Tenho uns métodos que retornam direto um
ResultSet, e um finalize() que fecha a conexão, se alguém se esqueceu no caminho.
Felipe \ no spam \ Leme writes:
Mauro,
Note que no seu bloco finally, se o rs.close() gerar uma exceção (o que deve ser raríssimo, pouco provável, mas possível.), a conexão não será fechada. Normalmente, eu faço algo do tipo:
finally {
JDBCUtilities.silentClose( stmt );
JDBCUtilities.silentClose( co );
}

// JDBCUtilties - possui varios close() e silentClose() methods (para ResultSet, Statement, Connection
public void silentClose( Statement stmt ) {
if ( stmt != null ) {
try {
stmt.close();
} catch( SQLException exc ) {
logger.warn( "error closing Statement", exc );
}
}
}
Note também que é importante fechar o Statement, e não o ResultSet (você poderia fechar os dois, mas pela especificação, quando um Statement é fechado os ResultSets associados a ele também são).
Felipe

Mauro martini-at-floripa.com.br |Sou java| wrote:
Eu normalmente uso assim:
Connection co = null;
ResultSet rs = null;
try {
co = pegaConn();
rs = executaUmQuery(co);
while (rs.next()) {
...
}
} catch (SQLException eSQL) {
debug("deu pau na base");
} finally {
if (rs != null) rs.close();
if (co != null) co.close();
}
[]s, ETA :-),
---
Mauro Ramos Martini
[EMAIL PROTECTED]
counter.li.org#225287

------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED] -------------------------------------------------------------------------

Responder a