Sobre NullPointerException

http://pt.stackoverflow.com/questions/63617/o-que-%C3%A9-anullpointerexception-e-quais-s%C3%A3o-suas-principais-causas

O NullPointerException lanado nas seguintes situaes:

1.
Tentar acessar um campo de uma instncia cuja referncia seja null.
2.

3.

Pessoa p = null;
String nome = p.nome; // <-- NullPointerException aqui.

Tentar acessar um mtodo de uma instncia cuja referncia seja null.

4.

Pessoa p = null;
String nome = p.getNome(); // <-- NullPointerException aqui.
5.
Tentar usar autounboxing de null. Este daqui em especial tende a ser uma pegadinha

para iniciantes em Java.

6.

Integer x = null;
int z = x; // <-- NullPointerException aqui.

Outro exemplo:
Integer x = null;
int z = x + 5; // <-- NullPointerException aqui.
7.
Lanar o NullPointerException diretamente (bvio).
throw new NullPointerException();
8.
Tentar lanar null como exceo.
9.
Exception x = null;
throw x; // <-- NullPointerException aqui.

10.
11.

12.

Tentar acessar o tamanho de uma varivel array que tenha o valor null.
String[] x = null;
int tamanho = x.length; // <-- NullPointerException aqui.

Tentar acessar um elemento de uma varivel array que tenha o valor null.

13.

String[] x = null;
String y = x[5]; // <-- NullPointerException aqui.
14. Tentar iterar null usando a sintaxe do for-each.
15.
String[] x = null;
16.
for (String y : x) { // <-- NullPointerException aqui.
17.
// ...
}
18. Tentar sincronizar (com o bloco synchronized) em null.
19.
Object x = null;
20.
synchronized (x) { // <-- NullPointerException aqui.
21.
// ...
}

As seguintes situaes NO causam NullPointerException, ao menos no diretamente:

1.
Atribuir null variveis de tipo objeto.
String x = null;
Atribuir null variveis de tipos primitivos. Isso no compila, logo no vai
dar NullPointerException :)
int x = null; // Erro de compilao!
3.
Passar null como parmetro de mtodos ou construtores.
4.
System.out.println(null); // Ok.
5.
String mensagem = JOptionPane.showInputDialog(null); // Ok.

2.

JPanel panel = new JPanel(null); // Ok.

Retornar null ou obter null como retorno de algum mtodo.
7.
public String getXpto() {
8.
return null;
9.
}
10.
11.
public void algumMetodo() {
12.
String xpto = getXpto(); // Ok. Recebe null.
}
13. Colocar o valor null em um array ou ler o valor null de um array.
14.
String[] array = new String[] {"a", "b", "c"};
15.
array[1] = null;
String valor = array[1]; // Ok. Recebe null.
16. Passar null como um parmetro varargs.
17.
private void metodo(String... parametros) {
18.
System.out.println(parametros);
19.
}
20.
21.
private void outroMetodo() {
22.
// No d NullPointerException, passa como parmetro um array com um
nico elemento que null.
23.
metodo(null);
24.
25.
// No d NullPointerException, passa como parmetro um array com dois
elementos null.
26.
metodo(null, null);
27.
28.
// No d NullPointerException, passa como parmetro null.
29.
metodo((String[]) null);
}
30. Iterar um array ou Collection com elementos null.
31.
String[] x = new String {"a", "b", null, "c"};
32.
for (String z : x) {
33.
System.out.println(z);
}

6.

Entretanto, apesar disso ser vlido e at til em algumas vezes, importante se ter em
mente que esta situao ainda bem convidativa a eventuais NullPointerExceptions,
vez que normalmente no esperado que a varivel do lao possa ser null:
String[] x = new String {"a", "b", null, "c"};
for (String z : x) {
System.out.println(z.length()); // <-- NullPointerException aqui.
}
34. Acessar um campo ou mtodo esttico a partir de uma referncia null. Isso daqui

uma pegadinha da linguagem Java, pois neste caso a nica coisa que importa o tipo
da varivel, e no o valor.
35.
36.

Integer t = null;
t.parseInt("123"); // Pegadinha: t null, mas isso NO D
NullPointerException!
37.
System s = null;
Object x = s.out; // No d NullPointerException!

importante ressaltar tambm que usar uma varivel para acessar um mtodo esttico
uma m prtica de programao, pois deixa o cdigo confuso ao utilizar uma varivel
de forma desnecessria. No faa isso.
38.
39.
40.

Tentar utilizar uma varivel local no-inicializada ou potencialmente noinicializada. Isso daqui d erro de compilao, logo no d NullPointerException.
Pessoa p;
p.setNome("Maria"); // Erro de compilao, a varivel p no foi inicializada.

41.
42.
43.

Pessoa q;
if (x > y) q = new Pessoa(); // Pode inicializar ou no, dependendo da
condio do if.
q.setNome("Maria"); // Erro de compilao, a varivel q possivelmente no foi
inicializada.

Vale ressaltar que esta regra s vale para variveis locais dentro dos mtodos e
construtores. Ela NO se aplica a campos de objetos e variveis estticas.
44. Lembre-se que a referncia this nunca ser null. Portanto
um NullPointerException nunca ser causado devido a tentativa de manipular-se
campos e invocar mtodos no objeto this.
45. Um construtor nunca retorna null. Portanto, sempre que for atribudo a uma varivel
o resultado da chamada de um construtor, garantidamente o que ser atribuda ser algo
que no null. Logo, tomando como exemplo o cdigo abaixo, impossvel que a
varivel p receba null, independente do que estiver ocorrendo dentro do construtor.
46.

Pessoa p = new Pessoa();

O operador instanceof sempre resulta em false quando testado com null, e nunca
lana NullPointerException. Logo, se ele resultar em true, o valor testado

garantidamente no nulo.
47.
48.
49.
50.

51.
52.
53.
54.

Animal p = ...;
if (p instanceof Cachorro) {
// Se entrar aqui, alm de sabermos que p instncia de Cachorro,
// tambm sabemos que p no null.

Casts nunca lanam NullPointerExceptions (mas podem

lanar ClassCastExceptions). Em especial, o cast realizado com o valor null sempre
ser bem sucedido.
Animal a = null;
// Recebe null. No lana NullPointerException e nem ClassCastException.
Cachorro c = (Cachorro) a;

55.

H quem pense que acessar um array em um ndice invlido causa

um NullPointerException.Isso no verdade. A exceo lanada neste caso
ser ArrayIndexOutOfBoundsException. Igualmente, tentar acessar os caracteres de
uma String em posies invlidas tambm no causa um NullPointerException e
neste caso a exceo ser StringIndexOutOfBoundsException.
56. Tentar concatenar null a uma String.
String x = "a" + null + "b"; // Recebe "anullb". No d NullPointerException.

Quase todos os casos onde um NullPointerException ocorre se deve a algum erro de

programao (e por causa disso, quase nunca faz sentido tentar trat-lo). Portanto, se voc
obter umNullPointerException, provavelmente voc (ou alguma outra pessoa) fez algo
errado no cdigo. Por esta razo, para se proteger contra o NullPointerException, o
principal a se fazer examinar a lgica do seu programa para certificar-se que voc nunca
cair em um caso onde um NullPointerException possa ser lanado, tal como mostrado nas
situaes acima no comeo desta resposta (e com os contra-exemplos acima tambm). A sua
principal arma contra esse tipo de erro o if:
if (x == null) {
// Faz alguma coisa. No utiliza o x aqui.
} else {
// Pode utilizar o x seguramente.
}

Tambm vlido colocar guardas em mtodos (e construtores) para se proteger de

referncias nulas vindas "de fora", usando o if. Isso no vai fazer o erro de programao

envolvendo referncias null desaparecerem, mas vai fazer eles se manifestarem mais
prximos de sua origem, tendo ento uma identificao mais fcil e portanto sendo mais
fceis de se rastrear e se corrigir. Alm disso, desta forma fica mais simples de garantir que
o seu mtodo est livre de erros, pois isso elimina uma categoria inteira de possveis erros
de programao que ele poderia ter e de brinde voc garante que ele no causar nenhum
efeito colateral estranho por ter executado apenas pela metade antes de ser abortado
pelo NullPointerException. A ideia que se o null estiver sendo usado de forma
inadequada (o que um erro de programao), ento o erro de programao no ser
responsabilidade do seu mtodo, e sim de quem o chamou de forma inadequada. Eis aqui
um exemplo simples:
public void cadastrarNome(String nome) {
if (nome == null) throw new NullPointerException("No pode cadastrar um nome
nulo.");
// ... Resto do mtodo.
}

Ou ento, voc pode usar uma exceo diferente:

public void cadastrarNome(String nome) {
if (nome == null) throw new IllegalArgumentException("No pode cadastrar um
nome nulo.");
// ... Resto do mtodo.
}

Isso tambm no se limita apenas validao de parmetros:

public double somarParcelas() {
if (parcela1 == null || parcela2 == null) {
throw new IllegalStateException("Nem todas as parcelas foram adquiridas");
}
// ... Resto do mtodo.
}

Uma outra forma de se implementar estes guardas utilizando-se o

mtodo Objects.requireNonNull(). Este mtodo lana um NullPointerException se receber
como parmetro null:
public void cadastrarNome(String nome) {
Objects.requireNonNull(nome, "No pode cadastrar um nome nulo.");
// ... Resto do mtodo.
}
public double somarParcelas() {
Objects.requireNonNull(parcela1, "A primeira parcela ainda no foi adquirida.");
Objects.requireNonNull(parcela2, "A segunda parcela ainda no foi adquirida.");
// ... Resto do mtodo.
}
Tambm vlido encapsular as suas referncias com a classe java.util.Optional:
String x = ...;
Optional<String> opt = Optional.ofNullable(x);
// Neste ponto, opt nunca ser nulo, e portanto pode ser
// sempre utilizado seguramente (embora o contedo dele possa ser nulo).
Assim como se proteger de nulls vindos de fora com os guardas mostrados acima, tambm
importante no propagar valores nulls se voc puder evitar isso. Por causa disso, bom
tambm evitar retornar nulls nos mtodos quando ele for devolver algo que representa

"vazio", "no inicializado", "no se aplica", "no existe" ou "no encontrado". Nestes casos,
eis o que voc poderia fazer:

Caso o seu mtodo retorne uma String, talvez seja melhor

retornar "" (uma String vazia) ao invs de null.

Caso o seu mtodo retorne um tipo empacotado de primitivo

(Integer, Double, Long, etc.), talvez seja melhor retornar zero ao invs de null. E se
for o caso de retornar zero, mudar o tipo de retorno para o tipo primitivo, se possvel,
tambm seria uma boa ideia.

Caso o seu mtodo retorne um array, talvez seja melhor retornar um array de
tamanho zero ao invs de null.

Caso o seu mtodo retorne uma Collection, talvez seja melhor

retornar Collections.emptyCollection(), Collections.emptyList() ou Collections.em
ptySet() ao invs de null.

Caso o seu mtodo retorne um Map, talvez seja melhor

retornar Collections.emptyMap() ao invs de null.

Caso o seu mtodo retorne um Stream, talvez seja melhor

retornar Stream.empty() ao invs de null.

Caso o seu mtodo retorne um Optional, ento uma pssima ideia

retornar null porque isso vai diretamente contra a ideia do Optional. Neste caso seria
melhor retornar Optional.empty() ao invs de null.

Caso o seu mtodo retorne alguma coisa XYZ para a qual no h algo que represente
o "vazio", "no inicializado", "no se aplica", "no existe" ou "no encontrado", talvez
mudar o tipo de retorno para Optional<XYZ> seja uma boa ideia. Ou ento voc
poderia usar o padro de projetoNull Object (que eu explicarei um pouco abaixo).
Na prtica, podemos fazer algo assim:
public class MeuBean {
private String nome;
private List<Pessoa> pessoas;
// Outros mtodos...
public String getNome() {
return nome == null ? "" : nome;
}

public List<Pessoa> getPessoas() {

return pessoas == null ? Collections.emptyList() : pessoas;
}

E por sinal, voltando aos parmetros, podemos fazer algo parecido com os guardas. Ao
invs de apenas rejeitar os nulls com excees podemos substitu-los pelos objetos vazios:
public void cadastrarNome(String nome) {
String nomeParaCadastrar = nome == null ? "Sem nome" : nome;
// ... Resto do mtodo.
}

Esta abordagem tem a vantagem que, diferente da anterior, os erros referentes ao uso
inadequado denull tendem de fato a desaparecer ao invs de apenas se moverem.
Entretanto, nem sempre esta abordagem possvel ou adequada.
E agora, vamos dar uma olhada melhor no padro de projeto Null Object. A ideia que voc
represente os conceitos de "vazio", "no existe", "no encontrado", etc. com uma instncia
de um objeto, ao invs de usar o null para isso. Eis aqui um exemplo dessa abordagem:
public class Pessoa {
private String nome;
private int idade;
// ... Mtodos.
// Mtodo que retorna um Null Object.
public static Pessoa ninguem() {

Pessoa naoTem = new Pessoa();

naoTem.nome = "Ningum";
naoTem.idade = 0;
return naoTem;
}

public class Carro {

private String modelo;
private String cor;
private int ano;
private Pessoa proprietario;
// ... Mtodos.
// Mtodo que retorna um Null Object.
public static Carro vazio() {
Carro carroVazio = new Carro();
carroVazio.modelo = "nenhum";
carroVazio.cor = "nenhuma";
carroVazio.ano = 0;
carroVazio.proprietario = Pessoa.ninguem();
return carroVazio;
}
}

Se voc puder trabalhar como interfaces, fica melhor para implementar o padro Null
Object:
public interface Animal {
public String fazerBarulho();
}
public class Cachorro implements Animal {
@Override
public String fazerBarulho() {
return "Au au";
}
}
public class Gato implements Animal {
@Override
public String fazerBarulho() {
return "Miau";
}
}
public class AnimalNenhum implements Animal {
@Override
public String fazerBarulho() {
return "";
}
}

Novamente, vale frisar que voc pode adotar uma destas abordagens para evitar o null se
possvel. Entretanto, nem sempre uma delas possvel e comum aparecerem algumas
situaes aonde realmente deve-se retornar null ou aceitar que algum campo, parmetro ou
varivel local possa ser null em circunstncias normais, e voc tem que saber conviver com
isso. Saber conviver com os nulls quando eles aparecerem sem causar
um NullPointerException faz parte do que o programador Java deve fazer.
No final, todas as formas de se evitar o NullPointerException recaem em organizar a lgica

do seu programa de modo a evitar cair em alguma das situaes aonde ele possa aparecer. E
em quase todas as situaes aonde um NullPointerException aparece, ele dever ser tratado
como um erro de programao (como de fato quase sempre ): entenda porque ele ocorre e
corrija o cdigo para no mais ocorrer.

Por fim, vale a pena recomendar o FindBugs. Trata-se de uma excelente e poderosa
ferramenta de anlise de cdigo Java, capaz de detectar uma grande quantidade de erros de
lgica, bugs, situaes perigosas e ms prticas de programao. E tudo isso obviamente
inclui muitas situaes que podem resultar em NullPointerException.
E se voc for usar o FindBugs (ou alguma outra ferramentas de verificao de cdigo com
caractersticas semelhantes), talvez voc encontre uma
anotao @NotNull, @NonNull ou @Nonnull, juntamente com alguma
anotao @Null, @Nullable ou @CheckForNull. Vrias pessoas de vrios projetos
diferentes criaram vrias verses destas anotaes com propsitos similares (o que ruim,
pois seria bem melhor se houvesse um nico @NotNull cannico e um
nico@Nullable cannico). Voc pode utilizar estas anotaes em campos, variveis,
parmetros e mtodos para dizer para as ferramentas capazes de entend-las que um null em
determinado lugar explicitamente proibido ou permitido. O FindBugs capaz de entender
tais anotaes, embora ele no necessite delas (mas se estiverem presentes, ele poder fazer
uma anlise ainda mais profunda).
Uma outra ferramenta poderosa o Checker Framework, que usa uma abordagem baseada
em anotaes (entre elas o @NonNull e o @Nullable) e funciona como um processador de
anotaes plugvel diretamente no compilador. Com ele, possvel at mesmo transformar
alguns locais onde poderia ocorrer um NullPointerException em erros de compilao,
evitando a dor-de-cabea de ter que rastre-los em testes e/ou debugging.
compartilharmelhorar esta resposta

editada 22/06 s 4:45

respondida 13/05 s 14:50

Victor Stafusa
8.63121744

No seria melhor apenas contornar o problema do

invs de lanar outra exceo? Patrick 13/05 s 21:50

@Patrick, s vezes sim, voc poderia colocar isso dentro do

de null. Mas na prtica, essa situao especfica de pedir a reentrada d
Saber e entender porque que o null surgiu em cada caso particular. 2.
cdigo caso no seja. 3. Se ele for de fato vlido, corrigir o cdigo par
recaindo em projetar a lgica do programa de forma a garantir que tod
segura. Victor Stafusa 13/05 s 21:58

Muito completa(+1). Julgo que falta apenas referir que mtodos que re
uma lista vazia, isto evitar que o uso do foreach
Iterar um array ou Collection com elementos null
ser lanada. No no caso de System.out.println(z);
de System.out.println(z.lenght()); ramaral

@ramaral Obrigado. Dei uma incrementada na minha resposta. Me dig

13:48
comentar

votar a favor8votar contra

A exceo NullPointerException lanada

quando se tenta usar um objecto que no tenha
sido ainda instanciado.
Tendo como base este classe:
public class Endereco{
public String rua;
public String localidade;
public Endereco(String rua, String
localidade){
this.rua = rua;
this.localidade = localidade;
}
public String getMoradaCompleta(){
return rua + "," + localidade;
}
}

As situaes mais usuais so as seguintes:

1 - Chamar um mtodo de instncia de um
objeto no instanciado.
public printMoradaCompleta(Endereco
endereco){
String morada =
endereco.getMoradaCompleta();
System.out.println(morada);
}

2 - Acessar ou modificar um campo de um

objeto no instanciado.
public printRua(Endereco endereco){
String rua = endereco.rua;
System.out.println(rua);
}

3 - Acessar ou modificar um elemento de um

array que no tenha sido inicializado.
public int
getSecondElementFromArray(int[] array){
return array[1];
}

Nas situaes 1 e 2 os mtodos iro falhar se

o endereco passado for null.
Na situao 3 o mtodo falhar
caso array seja null ou no tenha sido
atribudo nenhum valor ao segundo elemento
do array.
A forma de prevenir estas situaes verificar
se o parmetro passado ao mtodo no nulo
e caso seja lanar
uma IllegalArgumentException:
public printMoradaCompleta(Endereco
endereco){
if(endereco == null){

throw new
IllegalArgumentException("O endereo
no pode ser nulo");
}
String morada =
endereco.getMoradaCompleta();
System.out.println(morada);
}

Aqui pode ser encontrado um artigo mais

completo sobre o assunto:
compartilharmelhorar esta resposta

1 S queria te dizer que nomes de variveis e de mtodos deveriam iniciar

de nomes do Java (at a colorao de sintaxe aqui afetada por isso). Al
mtodo MoradaCompleta na classe Endereco
usagetMoradaCompleta ao invs de MoradaCompleta

Por fim, a sua resposta se limita a verificar se os parmetros de um mto

umIllegalArgumentException se for. Mas h muito mais alm disso
oNullPointerException. Aqui voc estaria apenas trocando o
umIllegalArgumentException no parmetro de um mtodo, o que p
principal da maioria dos iniciantes que usam Java, que de no saber ao
no. Victor Stafusa 13/05 s 13:58

Agradeo os seus comentrios. Todo o cdigo foi escrito diretamente na

sintaxe. Alm disso os trechos de cdigo so exemplificativos e neste ca
que apontou. claro que devemos sempre ter cuidado para evitar que er
fato, ser mais completa mas tornar-se-ia muito extensa, da o link ao arti
resposta que de certo ir complementar/superar a minha.

1 @ramaral no leve a mau. Mas, seu cdigo est fora dos padres do java
compila. Voc no poderia editar e arrumar ele ?
1 @wryel Editado. ramaral 13/05 s 22:38
comentar
votar a
favor5v
otar
contra

O que NullPointerException?
NullPointerException uma exceo lanada quando se tenta acessar membros
de um objeto que no existe.
Ou seja, o cdigo presume que uma determinada varivel referencia uma
instncia de um objeto e tenta acessar membros desta instncia; ento, quando
no h instncia de fato (a varivel aponta para null em vez de referenciar um
objeto), uma NullPointerException ser lanada.
Veja:
Pessoa pessoa = new Pessoa();

No cdigo acima, a varivel pessoa referencia um objeto - ela referencia uma

instncia de Pessoa.
Pessoa pessoa = null;

E no cdigo acima a varivel pessoa no referencia nenhum objeto. Podemos

dizer que ela "aponta para null" mas o mais usual dizermos que "a varivel
null".
Se voc passar para um mtodo qualquer esta varivel que null e este mtodo
tentar acessar um membro do objeto que ele presume existir, ser lanada
uma NullPointerException:
public void processaPessoa(Pessoa pessoa) {
int idade = pessoa.getIdade(); //se pessoa null, aqui ser lanada uma
NullPointerException.
...
}

Quais so as principais causas de

NullPointerException?
Esta exceo ocorre basicamente por dois motivos:
a) Erro de programao.
b) Erro de utilizao de uma biblioteca ou framework.
Uma NullPointerException lanada pelo seu cdigo um erro de programao
que voc cometeu. E se ela for lanada pelo cdigo de uma biblioteca ou
framework de terceiros, no necessariamente um erro de programao deles -
mais provvel que voc esteja utilizando a biblioteca da maneira errada (deixou
de configurar algo ou configurou da maneira errada, por exemplo).

Que mtodos ou prticas podem ser utilizadas para se

prevenir de NullPointerException?
Para se prevenir desta exceo voc deve evitar cometer erros de programao.
Por que um erro de programao se o teu cdigo lanar
uma NullPointerException? Porque se isso acontecer ento voc escreveu um
cdigo para ser utilizado de um jeito e o est usando de outro jeito.
Considere este mtodo:
public void processaPessoa(Pessoa pessoa) {
// ... no importa o cdigo que tem aqui.
}

O mtodo acima jamais deveria lanar

uma NullPointerException por pessoa ser null porque voc jamais deveria passar
uma varivel null para ele!
A assinatura do mtodo (seu nome e o parmetro que ele espera) deixa muito
bvio que ele precisa de um objeto do tipo Pessoa para funcionar. Passar uma
varivel null para este mtodo um erro de programao.
Tratar no comeo do mtodo se a varivel null pode ajudar a diagnosticar o erro
de programao mas eu considero uma prtica ruim pois o cdigo ficar sujo com
validaes que no so expressivas para o negcio.
Estas so validaes expressivas para o negcio:
public void processaPessoa(Pessoa pessoa) {
if (pessoa.getIdade() < 18) {
throw new BusinessException("A pessoa precisa ser maior de idade
para poder ser processada");
}
if (pessoa.getNotificacao() == null) {

throw new BusinessException("A pessoa precisa ter sido notificada

antes de ser processada.");
}
...
}

J esta outra uma validao ruim pois est sujando o cdigo com instrues que
no tem nada a ver com o negcio:
public void processaPessoa(Pessoa pessoa) {
if (pessoa == null) {
throw new InvalidArgumentExcetion("O parmetro 'pessoa' no pode
ser null.");
}
...
}

Este tipo de validao por vezes defendida por facilitar o diagnstico de erros,
mas no muito mais difcil perceber que pessoa null simplesmente deixando
estourar uma NullPointerExceptionmais abaixo. Ento eu opto por manter o
cdigo mais limpo e expressivo e no fao este tipo de validao.
Validaes como esta devem ser feitas nos nveis mais altos da aplicao, na
entrada de dados. Por exemplo:
// usurio entrou com o CPF da pessoa que ele quer processar
Pessoa pessoa = pessoas.find(cpf);
if (pessoa == null) {
throw EntityNotFoundException("No foi localizada nenhuma pessoa
com o CPF " + cpf);
}
processaPessoa(pessoa);

Um erro comum ao tentar prevenir NullPointerException

Por ingenuidade ou por alguma caracterstica no virtuosa, h programadores que
se livram de NullPointerException assim:
public void processaPessoa(Pessoa pessoa) {
if (pessoa != null) {
// cdigo para processar a pessoa.
} // fim do mtodo
}

O mtodo acima nunca vai falhar por pessoa ser null, mas o sistema
provavelmente vai falhar e vai ser do pior jeito possvel: silenciosamente.
Todo mundo vai ficar achando que algum foi processado mas isso no ocorreu e
nenhum alerta foi dado.
Ento a NullPointerException foi evitada ao custo do sistema ter sua integridade
corrompida.

Concluso
NullPointerException uma exceo lanada quando se tenta acessar membros
de um objeto que no existe.
A maneira de evit-la no validando no comeo do mtodo se os argumentos
so null (pelo menos no na maioria das vezes).
A maneira de evit-la validando a entrada de dados nos nveis mais altos da
aplicao (entradas do usurio, valores nos arquivos de configurao, fachada de

servios para consumo externo, etc.) e escrevendo cdigo expressivo para que os
seus consumidores saibam como consumi-lo.
Alm disso, algumas vezes vlido no domnio que um objeto no exista (veja
mais acima o exemplo da pessoa que no pde ser processada porque no tinha
sido notificada). Nestes casos, a existncia do objeto deve ser validada antes de
ele ser utilizado para que tenhamos um erro expressivo para o negcio em vez de
termos uma NullPointerException.
Por fim, bibliotecas e frameworks lanam NullPointerException quando so
utilizadas da maneira incorreta.
Quando uma NullPointerException lanada por bibliotecas ou frameworks
(pelo servidor de aplicativos, por exemplo) ficamos muito irados porque
queramos que eles tivessem validado os parmetros e tivessem lanado um erro
mais expressivo. Mas, como eu disse, geralmente mais difcil descobrir por que
uma varivel chegou nula at ali do que simplesmente identificar que um
determinado parmetro null.
compartilharmelhorar esta resposta

editada 14/05 s 13:56

respondida

Caff
6.825

comentar
votar a
favor5vo
tar contra

Essa exceo lanada sempre que se tentar acessar um objeto que ainda no foi
inicializado.
O que pode lanar a exceo:

Acessar mtodos de objetos nulos.

Acessar ou modificar campos de objetos nulos.

Pegar o length de um null

Acessar ou modificar os slots de um null
Lanar uma exceo como se fosse 'lanvel'

Em Java, necessrio sempre fazer duas coisas com qualquer objeto:

Declarar o objeto;

Inicializar o objeto (definir um valor diferente de null) - isso evita

o NullPointerException
Ex comuns:
1 caso:
ArrayList<String> texto = null; //definido como null
texto.add("texto");

2 caso: // pense que a classe pessoa j foi criada com o atributo nome e o get/set
Pessoa p;
System.out.Println(p.getNome());

3 caso:

ArrayList<String> texto = null;

int i = texto.length;

4 caso:
Pessoa p = new Pessoa("maria");
Pessoa pessoas[] = null;
pessoas[0] = p;

Em todos os casos, o que faltou?

INICIALIZAR O OBJETO (sem null)!!