Obtener un valor sin tener que anular la comprobación en Java

Muchas veces me encuentro con una comprobación nula cuando obtengo un valor de alguna jerarquía de datos para evitar NullPointerExceptions, que encuentro propenso a errores y necesita mucha repetitiva.

He escrito una rutina muy simple que me permite omitir la comprobación nula al buscar un 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();
    }
}

Lo uso un poco así ...

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

Lo anterior resulta en que obtengo un objeto Room o un valor nulo, sin tener que anular todos los niveles principales.

¿Qué opinas de lo anterior? ¿Estoy creando un patrón problemático? ¿Hay una mejor manera de hacer esto en tu opinión?

Tu solución es muy inteligente. El problema que veo es el hecho de que usted no sabe por qué recibió una null? ¿Fue porque la casa no tenía habitaciones? ¿Fue porque el pueblo no tenía casas? ¿Fue porque el país no tenía ciudades? ¿Fue porque hubo un nullen la posición 0 de la colección debido a un error incluso cuando hay casas en las posiciones 1 y superiores?

Si hace un uso extensivo de la NonPEclase, tendrá serios problemas de depuración. Creo que es mejor saber exactamente dónde se rompe la cadena que obtener silenciosamente algo nullque podría estar ocultando un error más profundo.

También esto viola la Ley de Demeter : country.getTown().getHouses().get(0).getLivingRoom(). La mayoría de las veces, violar algún buen principio hace que tenga que implementar soluciones poco ortodoxas para resolver el problema causado por la violación de dicho principio.

Mi recomendación es que lo use con precaución e intente resolver la falla de diseño que le obliga a incurrir en el antipatrón de choque de trenes (para que no tenga que usarlo en NonPEtodas partes). De lo contrario, puede tener errores que serán difíciles de detectar.

La idea está bien, de hecho muy buena. Dado que Java 8 Optionalexisten los tipos, se puede encontrar una explicación detallada en el tipo Java Opcional . Un ejemplo con lo que publicaste es

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

Y más adelante.

Su método funciona lo suficientemente bien para su propósito previsto, aunque devuelve nulls cuando obtiene un NullPointerExceptionsonido como un mal diseño.

Intente evitar nulls cuando pueda y solo páselos cuando representen algo o tengan un significado especial y solo devuélvalos cuando representen / signifiquen algo; de lo contrario, debe lanzar a NullPointerException. Esto evita errores y confusión. Si un Objectno debería ser null, un NullPointerdebería ser arrojado. Si un objeto puede ser, nullentonces nada saldrá mal cuando se pasa uno. De lo contrario, su método anterior funciona.

Puedo sentir tu dolor, pero la solución propuesta es una mala idea.

• Si uno de los captadores arroja un NPE por alguna otra razón, lo ignorará.
• Existe el riesgo de que ese lambda interno se convierta en un código horrible. Por ejemplo, si hay un nuevo requisito para devolver una constante especial cuando no hay casas en la ciudad, un programador perezoso puede extender la lamda, dejando todo envuelto NoNPE.get.
• Como ya se mencionó, Optional.mapes lo que estás buscando.
• La penalización de crear una nueva instancia de NullPointerException es a menudo significativa. Son muchos microsegundos, especialmente a medida que su pila de llamadas se está haciendo más grande. Es difícil predecir dónde se utilizará su utilidad.

Como nota al margen, NoNPEInterfacees un duplicado de java.util.function.Supplier.

En algunos casos, podría considerar usar una utilidad de evaluación de expresiones que esté presente en muchos marcos (por ejemplo: EL, SpEL):

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