Melhor pratica para Nullpointer

Programação Java
#1

Olá pessoal, tenho uma aplicação que em determinado momento é mostrado o codigo do ibge de um estado para um determinado endereço.
Para pegar ele é feito dessa maneira.

    endereco.getRua().getCidade().getCodigoIbge()

Esse código nesse caso não é obrigatório, e devo mostrar em branco minha duvida é qual a melhor pratica para isso.

Sei que posso tratar de 2 maneira com um try cacth ou encadear varios ifs

	public String getCodMunicipio() {
		try {
			return endereco.getRua().getCidade().getCodigoIbge().toString();
		} catch (NullPointerException e) {
			return "";
		}
	}
	public String getCodMunicipio() {
                if(endereco == null){
			return "";
		}else if(endereco.getCidade()==null){
			return "";			
		}else if(endereco.getCidade().getCodigoIbge()==null){
			return "";
		}else{
			enderecogetCidade().getCodigoIbge().toString();
		}	
        }
#2

Prefiro o primeiro. [=

#3

eu tb

#4 
public String getCodMunicipio() {  
     if(endereco != null && endereco.getRua() != null && endereco.getRua().getCidade() != null && endereco.getRua().getCidade().getCodigoIbge() != null)
         return endereco.getRua().getCidade().getCodigoIbge().toString();  
    }
    return ""; 
}
#5

também sou mais o segundo

muito melhor validar algo antes, do que esperar um NullPointer
nao é feio isso? esperar um nullpointer, estranho…

#6

[quote=igor_ks]também sou mais o segundo

muito melhor validar algo antes, do que esperar um NullPointer
nao é feio isso? esperar um nullpointer, estranho…[/quote]Por mim, não retornaria null em nenhum método. Todos os gets verificariam se é null, e retornam “”. Mas fui dentro da proposta dele. [=

#7

o duro de tratar uma nullPointer como no 1o caso, é que nunca sabemos onde ela está acontecendo, se é no getRua, getCidade e etc, mas dependendo do contexto é aceitável.

Boas práticas dizem que não devemos retornar null e sim um objeto em condições “especiais”, um exemplo clássico disso é retornar listas vazias ao invés de null, porém, não sei até onde isso se aplica. Por exemplo, talvez retornar um objeto cidade com tds atributos em branco.

abrasss

#8

Sim, a primeira vez que cliquei em “Responder” ia falar isso, “O melhor é nunca ter a necessidade de verificar se o campo está nulo”. Mas ai pensei que talvez estaria sendo grosseiro, e respondi conforme foi a pergunta dele e as respostas que li tb

#9

[quote=Hebert Coelho][quote=igor_ks]também sou mais o segundo

muito melhor validar algo antes, do que esperar um NullPointer
nao é feio isso? esperar um nullpointer, estranho…[/quote]Por mim, não retornaria null em nenhum método. Todos os gets verificariam se é null, e retornam “”. Mas fui dentro da proposta dele. [=[/quote]

o getCidade não tem como retornar “” pois ele retorna um objeto do tipo cidade.

Eu teria mesmo que validar todos os niveis da hierarquia até chegar ao CodigoIbge

#10

[quote=renanreismartins]o duro de tratar uma nullPointer como no 1o caso, é que nunca sabemos onde ela está acontecendo, se é no getRua, getCidade e etc, mas dependendo do contexto é aceitável.

Boas práticas dizem que não devemos retornar null e sim um objeto em condições “especiais”, um exemplo clássico disso é retornar listas vazias ao invés de null, porém, não sei até onde isso se aplica. Por exemplo, talvez retornar um objeto cidade com tds atributos em branco.

abrasss[/quote]

me indicaria algum livro sobre boas práticas?

#11

sim, pra esse assunto oque mais gostei foi clean code do kent beck, vai te ajudar mto

abrasss

#12

[quote=renanreismartins]o duro de tratar uma nullPointer como no 1o caso, é que nunca sabemos onde ela está acontecendo, se é no getRua, getCidade e etc, mas dependendo do contexto é aceitável.

Boas práticas dizem que não devemos retornar null e sim um objeto em condições “especiais”, um exemplo clássico disso é retornar listas vazias ao invés de null, porém, não sei até onde isso se aplica. Por exemplo, talvez retornar um objeto cidade com tds atributos em branco.

abrasss[/quote]

Nessa applicação tenho diversos cadastro de pessoas diferentes … fornecedores … clientes … usuarios etc.

Em clientes e somente em clientes o atributo cidade é Obrigadorio… nessa pratica eu teria no meu Controller fazer a validação do campo Cidade se retorno getCidade null posso fazer o if

if( pessoa.getcidade() == null){
//error
}

se retornar um objeto cidade com atributos em branco teria que fazer algo tipo

if( pessoa.getcidade() != new Cidade("","", null) ){
//error
}

Não fica estranho!!

#13

assim ficaria realmente muito ruim, então vc poderia verificar por id. Mas ai não diferencia da verificação apenas por null. Por isso falei que precisava consultar se nesse tipo de objetos seria interessante retornar uma instancia “especial” entendeu?

UPDATE: uma discussão interessante que achei no stackoverflow, essa resposta me parece a melhor:

fonte: http://stackoverflow.com/questions/1626597/should-functions-return-null-or-an-empty-object

abrasss

#14

[quote=renanreismartins]assim ficaria realmente muito ruim, então vc poderia verificar por id. Mas ai não diferencia da verificação apenas por null. Por isso falei que precisava consultar se nesse tipo de objetos seria interessante retornar uma instancia “especial” entendeu?

UPDATE: uma discussão interessante que achei no stackoverflow, essa resposta me parece a melhor:

fonte: http://stackoverflow.com/questions/1626597/should-functions-return-null-or-an-empty-object

abrasss[/quote]

Não teria algum exemplo.

#15

[quote=fernandoat][quote=Hebert Coelho][quote=igor_ks]também sou mais o segundo

muito melhor validar algo antes, do que esperar um NullPointer
nao é feio isso? esperar um nullpointer, estranho…[/quote]Por mim, não retornaria null em nenhum método. Todos os gets verificariam se é null, e retornam “”. Mas fui dentro da proposta dele. [=[/quote]

o getCidade não tem como retornar “” pois ele retorna um objeto do tipo cidade.

Eu teria mesmo que validar todos os niveis da hierarquia até chegar ao CodigoIbge

[/quote]Retorne um objeto novo então.

#16

[quote=Hebert Coelho][quote=fernandoat][quote=Hebert Coelho][quote=igor_ks]também sou mais o segundo

muito melhor validar algo antes, do que esperar um NullPointer
nao é feio isso? esperar um nullpointer, estranho…[/quote]Por mim, não retornaria null em nenhum método. Todos os gets verificariam se é null, e retornam “”. Mas fui dentro da proposta dele. [=[/quote]

o getCidade não tem como retornar “” pois ele retorna um objeto do tipo cidade.

Eu teria mesmo que validar todos os niveis da hierarquia até chegar ao CodigoIbge

[/quote]Retorne um objeto novo então. [/quote]

Em outro momento nessa applicação tenho cadastro cliente.

Em cliente e somente em cliente o atributo cidade é Obrigadorio… nessa pratica eu teria no meu Controller fazer a validação do campo Cidade se retorno getCidade null posso fazer o if

if(pessoa.getEndereco.getCidade()== new Cidade()){
//error
}

Não acha que fica estranho?

#17

O primeiro jeito é mais fácil de digitar.
O segundo é mais “certo”. A NullPointerException representa um erro de programação, ela não deve fazer parte do fluxo normal de um programa. Imagine se um dia você precisar fazer uma pequena lógica em um desses gets, se ele tiver um erro e der nullpointer você vai ter resultados incorretos sem nunca detectar o erro!

Para mim a melhor solução é essa aqui, que é robusta e não precisa digitar tanto quanto a opção dos vários IFs:

[quote=pmlm] public String getCodMunicipio() { if(endereco != null && endereco.getRua() != null && endereco.getRua().getCidade() != null && endereco.getRua().getCidade().getCodigoIbge() != null) return endereco.getRua().getCidade().getCodigoIbge().toString(); } return ""; } [/quote]

E você ainda pode desenvolver mais a idéia:

endereco.getRua().getCidade().getCodigoIbge()

Procure saber, segundo as regras de negócio, exatamente quais desses atributos podem estar nulos. Por exemplo, o endereço pode estar nulo, Ok. Mas se tiver um endereço será que é realmente opcional ter a Rua ? E se eu tiver a Cidade, faz sentido na regra de negócio que não tenha o Código IBGE?

Dessa maneira você testa só o que é esperado. Se alguma coisa diferente estiver nula, então é erro de aplicação mesmo e o mais correto é deixar a exceção estourar.

#18

EXCELENTE gomesrod!

fernando n tem mto o q exemplificar, segundo o cara do stackoverflow o lance é: NESTE CASO retornar nulo mesmo quando seu dado realmente não existe, concordo com ele, faz mais sentido.

agora o gomes deu uma excelente forma de melhorar a legibilidade do seu código.

abrassss

#19

[quote=gomesrod]O primeiro jeito é mais fácil de digitar.
O segundo é mais “certo”. A NullPointerException representa um erro de programação, ela não deve fazer parte do fluxo normal de um programa. Imagine se um dia você precisar fazer uma pequena lógica em um desses gets, se ele tiver um erro e der nullpointer você vai ter resultados incorretos sem nunca detectar o erro!

Para mim a melhor solução é essa aqui, que é robusta e não precisa digitar tanto quanto a opção dos vários IFs:

[quote=pmlm] public String getCodMunicipio() { if(endereco != null && endereco.getRua() != null && endereco.getRua().getCidade() != null && endereco.getRua().getCidade().getCodigoIbge() != null) return endereco.getRua().getCidade().getCodigoIbge().toString(); } return ""; } [/quote]

E você ainda pode desenvolver mais a idéia:

endereco.getRua().getCidade().getCodigoIbge()

Procure saber, segundo as regras de negócio, exatamente quais desses atributos podem estar nulos. Por exemplo, o endereço pode estar nulo, Ok. Mas se tiver um endereço será que é realmente opcional ter a Rua ? E se eu tiver a Cidade, faz sentido na regra de negócio que não tenha o Código IBGE?

Dessa maneira você testa só o que é esperado. Se alguma coisa diferente estiver nula, então é erro de aplicação mesmo e o mais correto é deixar a exceção estourar.
[/quote]

OMG realmente não tinha pensado, facilita quando se tem uma regra de negócios definida e nesse caso eu tenho só terei que validar se o endereço é null o restante quando há um endereço é obrigatório

Obrigado a todos.

#20

Só lembrando que eu fiz quote de uma sugestão que deram lá na primeira página no tópico, tinha passado despercebida na discussão. Acho que porque era um post pequenininho rs

Agora sim o cenário ideal… checar tudo faria parecer que está “fugindo” de analisar cuidadosamente a situação, assim fica mais bem definido.