Método que identifique uma consulta vazia

Muito obrigado.

Perfeito!!!

Não faltou um not ?

Acho que o condicional tá ao contrário.

if ( !rs.next() ) { // vazio } else { // nao ta vazio }

ViniGodoy:

Não faltou um not ?

Acho que o condicional tá ao contrário.

if ( !rs.next() ) { // vazio } else { // nao ta vazio }

Melhor ainda seria:

if ( rs.next() ) { // nao ta vazio } else { //vazio }

Eu discordo. Geralmente você vai trabalhar com o código dele cheio, e não vazio.

Então, o melhor mesmo é colocar um code guard e evitar identação:

if (!rs.next())
   return;

//Se a execução chegou aqui, é óbvio que não está vazio.

ViniGodoy:

Eu discordo. Geralmente você vai trabalhar com o código dele cheio, e não vazio.

Então, o melhor mesmo é colocar um code guard e evitar identação:

if (!rs.next())
   return;

//Se a execução chegou aqui, é óbvio que não está vazio.

Por questões de contratos de definição, eu concordo com você.
Mas, se tratando de probabilidade e uma vez sabendo, que geralmente estará cheio e não vazio, não é melhor usar a primeira comparação sendo a provavel, economizando uma "comparação", quando possível ?

return ((rs.next()) ? "cheio" : "vazio");

Estou questionando isso, pq foi isso que me ensinaram na faculdade. Não estou discordando de você. Valeu, viny!?

Editado:

A questão em que eu referenciei foi a qual você falou a cima usando if e else, e não esta contratual.
Contratos de definição, garantem seu objetivo com segurança, no blog do Philip Calçado, tem um artigo sobre isso. Achei bem interessante.

peerless:

Mas, se tratando de probabilidade e uma vez sabendo, que geralmente estará cheio e não vazio, não é melhor usar a primeira comparação sendo a provavel, economizando uma “comparação”, quando possível ?

E para que poupar uma única comparação, que por sinal é uma operação violentamente rápida, “as vezes”?
O sistema não vai ficar perceptivelmente mais eficiente e o código vai ficar um pouco mais confuso.

Só pense em “economizar” comandos se você estiver num loop muito intenso ou isso constutuir realmente um gargalo na sua aplicação, descoberto através de um profiler.

não seria melhor vc testar c o getString retorna algo??

if(rs.getString(field)!=null){ ///tem valor.... }

Existem 2 problemas na sugestão do Homisinho.

1. Você não pode usar o getString antes de estar num registro (ou seja, antes de usar next() pelo menos uma vez);
2. O método getString não retornará null, no lugar vai retornar um string contendo “\u0000”. Para testar se foi nulo, você tem que dar o getString e depois usar um método esquisito chamado wasNull();

utilizei da seguinte forma!!!

public int temalgo(){ try { if (rs.next() ) { return 1; } else { return 0; } } catch (SQLException ex) { ex.printStackTrace(); } return 0; }

e pra chamar o metodo:

TB1.open("SELECT NOME FROM tabela where NOME ='"+meuNome+"'"); if(TB1.temalgo()!=1){ ///n tem nada }

homisinho:

utilizei da seguinte forma!!!

public int temalgo(){ try { if (rs.next() ) { return 1; } else { return 0; } } catch (SQLException ex) { ex.printStackTrace(); } return 0; }

e pra chamar o metodo:

TB1.open("SELECT NOME FROM tabela where NOME ='"+meuNome+"'"); if(TB1.temalgo()!=1){ ///n tem nada }

mas pra que fazer todo este método, se bastasse você fazer o que o ViniGodoy está tentando explicar:

if (!rs.next()) // n tem nada …

E se for trabalhar com métodos, Java, oferece tipos booleanos, então… utilize true ou false.

boolean temAlgo() { boolean retorno ; try { if (rs.next()) retorno = true; } catch (ExceptionTal e) { } return returno; }

eu criei uma classe pra controlar algumas funções dos meus Statement…
como essa c tem algo na consulta ou n… e ela ficou assim:

public boolean temalgo(){ boolean retorno = false; try { if (rs.next() ) { retorno =true; } } catch (SQLException ex) { return retorno; } return retorno; }

Que tal assim?

public boolean temalgo(){ try { return rs.next(); } catch (SQLException ex) { throw new RuntimeException(ex); } }

bem mais enxuto…

valeu…