Nunca compare objetos (order é um objeto da classe String) com ==.
Use o método equals e, de preferência, comparando o valor que já é sabido com o valor a ser comparado:
darlan não estou discordando de vc mais o problema de testar o valor sabido primeiro é que ele pode vir nulo, por isso prefiro assim:
if(order.equals("Sayser time")
quando isFlag() é falso?
Rodrigo_Void
Agora eu buguei. if("Sayser time".equals(order)
No exemplo acima caso order seja null, vai dar false, não nullPointer.
No exemplo abaixo é o inverso, vai dar nullPointer caso order seja null: if(order.equals("Sayser time")
Por isso o correto seria o valor estatico na frente e o variável como parametro do equals.
darlan_machado
Mas a ideia de se comparar desta maneira é, justamente, evitar um NPE.
Teoricamente, você nunca deve esperar que o sistema, negocialmente, estoure o NPE. Afinal, ou é igual a Sayser time ou Sayser Date, não? Qualquer coisa diferente disso, incluindo null, é diferente de ambos.
Entendeu?
Rodrigo_Void
Exatamente, mas por isso, vc faz: if("Sayser time".equals(order))
pra evitar NPE, ou faz: if(order != null && order.equals("Sayser time"))
O fato é q n pode deixar ocorrer NPE e fazendo apenas: if(order.equals("Sayser time"))
pode ocorrer. Em nenhum dos casos vai dar true quando for null, mas no último vai dar erro e quebrar a rotina.
O fato é q precisa tratar a possibilidade de vir NULL, nem que seja com try/catch
B
blayd2015
sim…sim…por eu disse que não estava discordando de vc, só prefiro dizer que
Rodrigo_Void1 like
Só abrindo mais um parenteses:
(se tratando da variavel order receber a leitura do console, não vai vir null, no máximo vazio, mas seguir o padrão sempre)
darlan_machado
Isso é uma questão de abordagem.
Boas práticas dizem para, em caso de comparação, utilizar o valor conhecido antes.
darlan_machado
Certamente.
Além disso, o ponto principal do tópico é a questão do uso de == ou equals.
Tbm tem o Objects.equals(val1, val2), por sinal uso(usava) bastante.
Atualmente 100% kotlin, então no problems mais.
darlan_machado1 like
@blayd2015, a questão não é morte ao NPE, a questão é que NPE é um indício forte de que o programador não fez alguma coisa direito.
É por isso que tanto se insiste em inversão de controle, injeção de dependências e afins.