Evitando as irritantes null pointer exceptions

Olá pessoal! Hoje eu vou falar sobre um dos crashes mais irritantes e comuns em Android, as NullPointerException. Acredite,...

Data de publicação: 25/09/2017

Olá pessoal! Hoje eu vou falar sobre um dos crashes mais irritantes e comuns em Android, as NullPointerException. Acredite, se você está começando em Android, você vai ter a sua primeira null pointer exception em breve se já não a teve. Para quem não sabe do que se trata, essa exceção é lançada quando você tenta utilizar um objeto nulo.
Se isso acontecer o app vai “crashar” e fechar instantaneamente o que é muito frustrante para o usuário, então nós temos que nos esforçar para evitar que isso aconteça.
Então basicamente nós não devemos fazer nenhuma operação com um objeto se a gente não tiver total certeza que esse é de fato um objeto válido. Nós poderíamos fazer condicionais como no código abaixo:
01_03
Ou mesmo de uma forma mais elegante usando a forma reduzida do “if”.
02_07
Isto funciona, mas quando o projeto começa a crescer muito isso pode começar a se tornar realmente irritante e repetitivo e se você esquecer de fazer essa verificação uma vez que seja, o problema ressurge. Então pensando sobre tudo isso, eu cheguei a uma possível solução. Esse não é nenhum padrão de melhores práticas ou qualquer coisa do tipo, é apenas um formato de código que eu desenvolvi baseado na idéia de tentar fazer os meus models “null proof”.
A idéia é que devemos produzir código que não permita que os nossos models sejam nulos em momento algum, mas isso pode ainda assim acontecer por vários motivos, então se isso acontecer por qualquer motivo, o app não deve “crashar” de maneira nenhuma. Se você não tem a informação necessária para exibir na tela, não mostre nada ou mostre algum valor padrão, mas o app não deve nunca “crashar” e fechar. Então eu comecei a criar getters para as propriedades dos meus models que verificam antes se o objeto é válido e se a propriedade em si é válida e se tudo estiver ok retorna o valor, senão retorna um valor padrão e nenhuma exceção será lançada. Um exemplo de como isso ficaria no código:
03_03
Ou em Kotlin o código ainda mais limpo:
03_07
Em Kotlin você poderia definir a variável para não aceitar valores nulos, mas dependendo de onde vem os dados, se você está pegando os dados através de uma requisição via rest api usando Retrofit por exemplo, se o valor vindo do json é nulo ou ausente, Kotlin vai lançar uma exceção, então a não ser que você tem como ter certeza que todas as propriedades terão valores válidos a todo tempo, melhor usar campos opcionais (Campos que permitem valores nulos em Kotlin).
Espero que esse texto possa ser útil para alguém e eu adoraria ouvir as idéias de vocês a respeito. Como você enfrenta esse tipo de problema?

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

6 − dois =

Posts relacionados

  1. Sobre a Dextra

    Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes.

  2. Categorias

Scroll to top