Alguem poderia me ajudar, o while não executa o if e começa novamente
while (isFlag())
{
System.out.print("…");
String order = entry.nextLine();
System.out.println("");
//Date
Date d = new Date();
String dStr = java.text.DateFormat.getDateInstance(DateFormat.MEDIUM).format(d);
//Date
if((order == "Sayser time") || (order == "Sayser Date"))
{
System.out.println(">>> "+ d);
}
}
Simplesmente não executa o if
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:
if("Sayser time".equals(order) || "Sayser Date".equals(order)) {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?
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.
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?
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
sim…sim…por eu disse que não estava discordando de vc, só prefiro dizer que
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)
Isso é uma questão de abordagem.
Boas práticas dizem para, em caso de comparação, utilizar o valor conhecido antes.
Certamente.
Além disso, o ponto principal do tópico é a questão do uso de == ou equals.
morte ao NullPointerException…kkkkkkk
public static void main(String[] args) {
String value = null;
Optional<String> a = Optional.ofNullable(value);
if(!a.isPresent()){
value = a.orElse("teste");
}
System.out.println(value);
}Tbm tem o Objects.equals(val1, val2), por sinal uso(usava) bastante.
Atualmente 100% kotlin, então no problems mais.
@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.
Resumindo:
valeu, ajudou bastante