Buscando um valor sem precisar fazer nulo no Java

Muitas vezes me vejo checando nulo ao buscar um valor de alguma hierarquia de dados para evitar NullPointerExceptions, que considero propenso a erros e que precisa de muita informação.

Eu escrevi uma rotina muito simples que permite ignorar a verificação nula ao buscar um objeto ...

public final class NoNPE {

    public static <T> T get(NoNPEInterface<T> in) {
        try {
            return in.get();
        } catch (NullPointerException e) {
            return null;
        }
    }

    public interface NoNPEInterface<T> {
        T get();
    }
}

Eu uso um pouco assim ...

Room room = NoNPE.get(() -> country.getTown().getHouses().get(0).getLivingRoom());

O resultado acima resultou na obtenção de um objeto Room ou um nulo, sem a necessidade de nulo verificar todos os níveis pai.

O que você acha do exposto? Estou criando um padrão problemático? Existe uma maneira melhor de fazer isso na sua opinião?

Sua solução é muito inteligente. O problema que vejo é o fato de você não saber por que recebeu um null? Foi porque a casa não tinha quartos? Foi porque a cidade não tinha casas? Foi porque o país não tinha cidades? Foi porque houve um nullna posição 0 da coleção devido a um erro, mesmo quando há casas nas posições 1 e superiores?

Se você usar extensivamente a NonPEclasse, terá sérios problemas de depuração. Eu acho que é melhor saber onde exatamente a cadeia está quebrada do que obter silenciosamente um nullque poderia estar escondendo um erro mais profundo.

Isso também viola a Lei de Deméter : country.getTown().getHouses().get(0).getLivingRoom(). Freqüentemente, violar algum bom princípio faz com que você implemente soluções não-ortodoxas para resolver o problema causado pela violação de tal princípio.

Minha recomendação é que você o use com cautela e tente solucionar a falha de design que faz com que seja necessário incorrer no antipadrão de naufrágio do trem (para que você não precise usá-lo em NonPEqualquer lugar). Caso contrário, você pode ter erros que serão difíceis de detectar.

A ideia é boa, muito boa de fato. Como os Optionaltipos existem no Java 8 , uma explicação detalhada pode ser encontrada no tipo Java Opcional . Um exemplo com o que você postou é

Optional.ofNullable(country)
    .map(Country::getTown)
    .map(Town::Houses);

E mais adiante.

Seu método funciona bem o suficiente para a finalidade a que se destina, embora retorne nulls quando você obtém um NullPointerExceptionsom como um design ruim.

Tente evitar nulls quando puder e só passá-los quando eles representam algo ou têm um significado especial e apenas os devolve quando eles representam / significam algo - caso contrário, você deve lançar a NullPointerException. Isso evita bugs e confusão. Se um Objectnão deveria ser null, um NullPointerdeveria ser lançado. Se um objeto puder ser null, nada dará errado quando um for passado. Caso contrário, seu método acima funcionará.

Sinto sua dor, mas a solução proposta é uma má ideia.

• Se um dos getters lançar um NPE por algum outro motivo, você o ignorará.
• Há um risco de que esse lambda interno se transforme em código horrível. Por exemplo, se houver um novo requisito para retornar uma constante especial quando não houver casas na cidade, um programador preguiçoso poderá estender a lamda, deixando tudo embrulhado NoNPE.get.
• Como já mencionado, Optional.map é o que você está procurando.
• A penalidade de criar uma nova instância de NullPointerException é frequentemente significativa. São muitos microssegundos, principalmente porque a pilha de chamadas está aumentando. É difícil prever onde seu utilitário será usado.

Como observação lateral, NoNPEInterfaceé uma duplicata dejava.util.function.Supplier .

Em alguns casos, você pode considerar o uso de utilitários de avaliação de expressão que estão presentes em muitas estruturas (por exemplo: EL, SpEL):

evaluateProperty(country, "town.houses[0].livingRoom")