qual codigo ficaria melhor ? outras sugestoes sao bem vindas
if(objeto.getMetodo() != null){
} else if(objeto.getMetodo2() != null{
}
try{
objeto.getMetodo();
//faz algo
}catch(nullpointerexception e){
try{
objeto.getMetodo2();
//faz algo
}cath(nullpointerexception e1){
throw new MinhaException();
}NullPointerException é uma exceção que indica um erro sério de programação, e tratá-lo denota preguiça.
Nesse caso, use e abuse dos ifs.
pugnator são duas coisas diferentes.
A primeira opção com IF ELSE é condicional, ou seja, se situação X(objeto.getMetodo() != null) for verdadeira então ele executa as instruções senão, se y(objeto.getMetodo2() != null) for contemplada então execute tais instruções.
Já o bloco try catch é no estilo “execute x instrução, se der erro execute y instrução”
as instruções do try são sempre executadas, e do catch somente serão executadas se a instrução anterior gerar uma exceção.
Espero que tenha ajudadp.
obrigado pelas respostas, Meu post foi apenas para verificar qual a melhor opcao, tendo em vista que tenho tentado diminiuir a quantidade de ifs no código.
entanglement,
baseado no que vc falou, nao é o meu caso.
A regra de negocio contempla duas situacoes uma onde o metodo1(que é um relacionamento) vem preenchido e outra situacao o metodo2(outro relacionamento) vem preenchido. Sempre um dos dois vem vazio (null). Não cabe aqui discutir se isso é correto ou nao, alguém fez assim e eu tenho que usa dessa maneira.
Abs
nunca espera um nullpointerexception, trate-o antes 
Voce vai atravessar um buraco muito fundo, e tem uma tabua que pode te ajudar a fazer uma ponte e passar sem cair nesse buraco
O que vc vai preferir
if: Se eu colocar essa tabua, tenho menos risco de cair
esperar exception: Vou pular, se eu cair quer dizer que era melhor eu ter colocado a tabua
Seila da onde tirei isso, mas acho que se encaixa hehe
obrigado pelas respostas, Meu post foi apenas para verificar qual a melhor opcao, tendo em vista que tenho tentado diminiuir a quantidade de ifs no código.
entanglement,
baseado no que vc falou, nao é o meu caso.
A regra de negocio contempla duas situacoes uma onde o metodo1(que é um relacionamento) vem preenchido e outra situacao o metodo2(outro relacionamento) vem preenchido. Sempre um dos dois vem vazio (null). Não cabe aqui discutir se isso é correto ou nao, alguém fez assim e eu tenho que usa dessa maneira.
Abs
obrigado pelas respostas, Meu post foi apenas para verificar qual a melhor opcao, tendo em vista que tenho tentado diminiuir a quantidade de ifs no código.
entanglement,
baseado no que vc falou, nao é o meu caso.
A regra de negocio contempla duas situacoes uma onde o metodo1(que é um relacionamento) vem preenchido e outra situacao o metodo2(outro relacionamento) vem preenchido. Sempre um dos dois vem vazio (null). Não cabe aqui discutir se isso é correto ou nao, alguém fez assim e eu tenho que usa dessa maneira.
Abs
edit: duplicado (erro 404)
Tecnicamente não fará diferença, pois vc quer se livrar do IF porém terá muitos catch.
É muito mais lento tratar uma exceção que checar contra null. Há muita gente que diz que não deve haver muitos ifs no seu código, mas não tratar um null é realmente preguiça.
O que eu vi muito por aí é que as pessoas não sabem usar os operadores lógicos, então os programas ficam cheios de ifs desnecessários. Você pode escrever isto aqui:
Tem muita gente que não sabe que o “&&” é esperto: se a primeira condição é falsa, nem executa a segunda. Então é muito seguro escrever:
if (algumaCoisa != null && algumaCoisa.estaFuncionando()) {
}em vez de:
if (algumaCoisa != null) {
if (algumaCoisaEstaFuncionando()) {
...
}
}Esses ifs encadeados entram realmente na categoria “excesso de ifs”.
[quote=entanglement]É muito mais lento tratar uma exceção que checar contra null. Há muita gente que diz que não deve haver muitos ifs no seu código, mas não tratar um null é realmente preguiça.
O que eu vi muito por aí é que as pessoas não sabem usar os operadores lógicos, então os programas ficam cheios de ifs desnecessários. Você pode escrever isto aqui:
Tem muita gente que não sabe que o “&&” é esperto: se a primeira condição é falsa, nem executa a segunda. Então é muito seguro escrever:
if (algumaCoisa != null && algumaCoisa.estaFuncionando()) {
}em vez de:
if (algumaCoisa != null) {
if (algumaCoisaEstaFuncionando()) {
...
}
}Esses ifs encadeados entram realmente na categoria “excesso de ifs”.
[/quote]
Verdade, eu utilizo muito isso if (algumaCoisa != null && algumaCoisa.estaFuncionando()) {
Sempre prevenindo uma possivel excessao.
[quote=pugnator]qual codigo ficaria melhor ? outras sugestoes sao bem vindas
if(objeto.getMetodo() != null){
} else if(objeto.getMetodo2() != null{
}
try{
objeto.getMetodo();
//faz algo
}catch(nullpointerexception e){
try{
objeto.getMetodo2();
//faz algo
}cath(nullpointerexception e1){
throw new MinhaException();
}[/quote]
Mesmo que a exceção não fosse um null pointer a regra é sempre verificar os dados que vc tem (Não confie que alguem vai lançar exception, verifique antes).
Exceptions são , como o nome indica, inesperadas. e vc sabe que algo pode acontecer, então não é mais inesperado, então vc precisa verificar. O fato de verificar com o if é uma escolha programática. O que interessa é que vc precisa tomar uma decisão (seja ela com if ou switch ou qq outra coisa) e vc deve tomá-la sempre que vc precisar.
O negócio de “muitos iffs” no código tem que ver com decisões desnecessárias. O clássico é usar if para saber se a classe é A ou B e chamar métodos diferentes. Isto é algo que se resolve com polimorfismo (que é uma das formas de tomar decisões que não usa if). Outro exemplo é o uso do padrão strategy ( que usa o polimorfismo para substituir um switch). Outro exemplo é procurar com for e if em vez de usar um mapa, etc… Ninguém pode censurar o uso de if. O que se censura é o abuso do if quando existem outras alternativas. Quando o java 8 chegar vc vai ver pessoas dizendo que for é ruim e que lambda é melhor que usar for é incorreto. Mas isso é um exagero. O incorreto é usar for quando um lambda for suficiente, mas nem sempre os lambdas podem tomar a vez do for. Por outro lado, os lambdas tendem a secar os for fazendo apenas 1 e não N…
Além da regra de : não confie que alguém vai lançar exeception, tem a regra : não use try/catch para tomar decisões. O try catch é uma contruções “fora de fluxo” e sempre que o sistema entre em “fora de fluxo” algo está errado. Um programa correto não sai fora do fluxo.