Pessoal, estou em um projeto e temos muitos trechos de código como esse:
if (obj1 == null || obj2 == null ){...}
Em alguns casos os blocos if tem mais informações ficando um pouco poluído, levando em consideração que no momento um refactor da lógica não pode ser feito, vale a pena criar método como o seguinte?
boolean isNull(Object o){
return o == null;
}
if (isNull(obj1) || isNull(obj2) ){...}Dependendo do caso você pode usar o bloco try catch. As vezes o codigo tende a ficar mais poluido levando em consideração a performance. Nem todo codigo bonitinho e toda logica curta e’ necessariamente eficiente.
Isso não é uma boa prática, NullPointerException nunca deve ser esperada / capturada, deve ser tratada pra que nunca aconteça. Você deve capturar regras de negócio e não erros de programador.
Vale sim, o código fica mais limpo. Porém melhor ainda, no meu ponto de vista, é usar o Optional (do Java 8, ou do Google guava, caso o projeto seja < java 8), onde todo objeto é “wrappado” pelo Optional, e voce pode verificar com Optional.isEmpty
Isso não é uma boa prática, NullPointerException nunca deve ser
esperada / capturada, deve ser tratada pra que nunca aconteça. Você deve
capturar regras de negócio e não erros de programador.
Na teoria ne’ !!!, na pratica você precisa conviver com erros de terceiros. Imagina você usar uma classe e ela dispara uma exception.
Pode acontecer coisas inesperadas, quando ta’ rodando um codigo que você julga limpo. exemplo : falhas na JVM, falhas de memoria, overflow de divisão e por ai vai …
NullPointerException deve ser sempre esperado e devidamente tratado
Concordo que deve ser esperado e tratado, mas com ifs e nao try catch
Concordo que deve ser esperado e tratado, mas com ifs e nao try catch
Imagina um metodo que vc chama 1000 classes de terceiros, seriam 1000 ifs, o codigo vai ficar mais poluido que 1 (um) unico try catch, ou talvez um par deles.
“Imagina um metodo que vc chama 1000 classes”
Amigão, se tua classe tá chamando outras 1000, coisa errada já tem, antes de vc colocar seu try com certeza 
“Imagina um metodo que vc chama 1000 classes”
Amigão, se tua classe tá chamando outras 1000, coisa errada já tem, antes de vc colocar seu try com certeza
Que e’ amigão, você faz parte do movimento anti try catch ?
Nem um pouco, como já disse, se tua classe está chamando outras 1000, a coisa já está errada, antes de vc colocar try, if, while, break, e quantas outras palavras reservadas a mais.
Se tu quer dar exemplos de uso, de exemplos coniventes.
Ah vc tá coando mosquitos e engolindo camelos. O importante e’ saber que try catch pra casos de exception e’ estremamente eficiente.
Alem de não gostar de try catch, quer limitar a quantidade de classes que minha classe pode chamar ?
Melhor vc procurar um psicologo dos bytes !!!
Estamos falando de código limpo e boas práticas amigo, por isso ele disse que tem algo errado. Concordo com ele, se sua classe está chamando outras 1000 está mto acoplado e pouco coeso
Estamos falando de código limpo e boas práticas amigo, por isso ele
disse que tem algo errado. Concordo com ele, se sua classe está chamando
outras 1000 está mto acoplado e pouco coeso
Penso que vc nunca desenvolveu sistemas grandes.
Chamar 1000 classes não e’ nada.
Onde eu escrevi classe imagina sua classe principal extendendo Application e dentro dela existem 100 classes e cada classe chama 10 classes. No final serão 1000 ifs desnecessarios, que especie de codigo limpo e’ esse que vc segue ?
OMG, se é isso que vc está se referindo, então pior ainda, vc deve colocar try catch pra nullpointerexpcetion em tudo, já que não confia em código terceiro assim. Imagina se usar Spring então
OMG, se é isso que vc está se referindo, então pior ainda, vc deve
colocar try catch pra nullpointerexpcetion em tudo, já que não confia em
código terceiro assim. Imagina se usar Spring então
Vai com esse seu discurso de usar ifs no lugar de try catch, la’ pra turma da oracle, os caras vão demorar uma semana pra se recuperar de tanta dor de garganta de tanto rir.
Se não leu o livro “Effective Java, second edition” recomendo a leitura
Se não leu o livro “Effective Java, second edition” recomendo a leitura
E eu recomendo você para de colar na faculdade. E esvaziar essa sua mente cheia de teoria.
"quer limitar a quantidade de classes que minha classe pode chamar ?"
Limitar não, mas tem uns conceitos em programação que são importantes.
Orientação a objetos, Design patterns, inclusive os criadores daqui (guj), caelum, alura, casa do código pegam bastante no pé em relação a isso, mas provavelmente tu não deve saber.
"Penso que vc nunca desenvolveu sistemas grandes. "
Pô cara, porque tu não muda teu nick ? de j-menezes para developer-sistemas-grandes-legados ?
E se o cara nunca desenvolveu ? tu sabe a idade ? tu sabe oq ele faz ?
E antes um cara da oracle, que alguém que só escreve em blog né, e escreve merda ainda por cima.
"quer limitar a quantidade de classes que minha classe pode chamar ?"
Limitar não, mas tem uns conceitos em programação que são importantes.
Orientação a objetos, Design patterns, inclusive os criadores daqui (guj), caelum, alura, casa do código pegam bastante no pé em relação a isso, mas provavelmente tu não deve saber.
"Penso que vc nunca desenvolveu sistemas grandes. "
Pô cara, porque tu não muda teu nick ? de j-menezes para developer-sistemas-grandes-legados ?
E se o cara nunca desenvolveu ? tu sabe a idade ? tu sabe oq ele faz ?
E antes um cara da oracle, que alguém que só escreve em blog né, e escreve merda ainda por cima
Merda quem escreve e’ vocẽ !!!. Você sim devia mudar seu nome de igomes pra “igomes-nunca-desenvolveu-nada-de-verdade”.
vou mudar, e colocar amo-try-catch-forever
Muda pra que desejar e usa da forma que convir, alias isso e’ problema seu e não meu.