Цепочка нулевой проверки и перехват исключения NullPointerException

Веб-служба возвращает огромный XML, и мне нужно получить доступ к его глубоко вложенным полям. Например:

return wsObject.getFoo().getBar().getBaz().getInt()

Проблема заключается в том, что getFoo(), getBar(), getBaz()может все возвращается null.

Однако, если я проверю nullво всех случаях, код станет очень подробным и трудным для чтения. Более того, я могу пропустить проверки по некоторым полям.

if (wsObject.getFoo() == null) return -1;
if (wsObject.getFoo().getBar() == null) return -1;
// maybe also do something with wsObject.getFoo().getBar()
if (wsObject.getFoo().getBar().getBaz() == null) return -1;
return wsObject.getFoo().getBar().getBaz().getInt();

Допустимо ли писать

try {
    return wsObject.getFoo().getBar().getBaz().getInt();
} catch (NullPointerException ignored) {
    return -1;
}

или это будет считаться антипаттерном?

Отлов NullPointerException- действительно проблематичное занятие, поскольку оно может произойти практически где угодно. Очень легко получить один из бага, поймать его случайно и продолжить, как будто все в порядке, тем самым скрывая реальную проблему. С этим так сложно справиться, поэтому лучше избегать его вообще. (Например, подумайте об автоматической распаковке нуля Integer.)

Я предлагаю вам использовать Optionalвместо этого класс. Часто это лучший подход, когда вы хотите работать с ценностями, которые либо присутствуют, либо отсутствуют.

Используя это, вы можете написать свой код следующим образом:

public Optional<Integer> m(Ws wsObject) {
    return Optional.ofNullable(wsObject.getFoo()) // Here you get Optional.empty() if the Foo is null
        .map(f -> f.getBar()) // Here you transform the optional or get empty if the Bar is null
        .map(b -> b.getBaz())
        .map(b -> b.getInt());
        // Add this if you want to return null instead of an empty optional if any is null
        // .orElse(null);
        // Or this if you want to throw an exception instead
        // .orElseThrow(SomeApplicationException::new);
}

Почему необязательно?

Использование Optionals вместо nullзначений, которые могут отсутствовать, делает этот факт очень заметным и понятным для читателей, а система типов гарантирует, что вы случайно не забудете об этом.

Вы также получаете доступ к методам для более удобной работы с такими значениями, например, mapи orElse.

Отсутствие действительно или ошибка?

Но также подумайте, является ли это допустимым результатом для промежуточных методов, возвращающих ноль, или это признак ошибки. Если это всегда ошибка, то, вероятно, лучше создать исключение, чем возвращать специальное значение, или чтобы сами промежуточные методы генерировали исключение.

Может еще варианты?

Если, с другой стороны, действительны отсутствующие значения из промежуточных методов, может быть, вы также можете переключиться на Optionals для них?

Тогда вы можете использовать их так:

public Optional<Integer> mo(Ws wsObject) {
    return wsObject.getFoo()
        .flatMap(f -> f.getBar())
        .flatMap(b -> b.getBaz())
        .flatMap(b -> b.getInt());        
}

Почему не по желанию?

Единственная причина, по которой я могу не использовать, Optional- это если это действительно критичная для производительности часть кода, и если накладные расходы на сборку мусора оказываются проблемой. Это происходит потому , что несколько Optionalобъектов выделяются каждый раз , когда код выполняется, и виртуальная машина может не быть в состоянии оптимизировать те прочь. В этом случае ваши оригинальные if-тесты могут быть лучше.

Предлагаю подумать Objects.requireNonNull(T obj, String message). Вы можете строить цепочки с подробным сообщением для каждого исключения, например

requireNonNull(requireNonNull(requireNonNull(
    wsObject, "wsObject is null")
        .getFoo(), "getFoo() is null")
            .getBar(), "getBar() is null");

Я бы посоветовал вам не использовать специальные возвращаемые значения, например -1. Это не стиль Java. Java разработала механизм исключений, чтобы избежать этого старомодного способа, пришедшего из языка C.

Метание NullPointerExceptionтоже не лучший вариант. Вы можете указать собственное исключение (сделав его отмеченным, чтобы гарантировать, что оно будет обработано пользователем, или снимите флажок, чтобы обработать его более простым способом) или использовать конкретное исключение из используемого вами синтаксического анализатора XML.

Предполагая, что структура классов действительно находится вне нашего контроля, что, по-видимому, так и есть, я думаю, что обнаружение NPE, как предлагается в вопросе, действительно является разумным решением, если только производительность не является серьезной проблемой. Одно небольшое улучшение могло бы заключаться в том, чтобы обернуть логику throw / catch, чтобы избежать беспорядка:

static <T> T get(Supplier<T> supplier, T defaultValue) {
    try {
        return supplier.get();
    } catch (NullPointerException e) {
        return defaultValue;
    }
}

Теперь вы можете просто:

return get(() -> wsObject.getFoo().getBar().getBaz().getInt(), -1);

Как уже отмечал Том в комментарии,

Следующее заявление не подчиняется закону Деметры ,

wsObject.getFoo().getBar().getBaz().getInt()

Вы хотите, intи можете получить это Foo. Закон Деметры гласит: никогда не разговаривай с незнакомцами . В вашем случае вы можете скрыть реальную реализацию под капотом Fooи Bar.

Теперь вы можете создать метод в Fooизвлечь intиз Baz. В конечном счете, Fooбудет иметь Barи Barмы можем получить доступ , Intне подвергая Bazнепосредственно Foo. Таким образом, нулевые проверки, вероятно, разделены на разные классы, и только необходимые атрибуты будут разделяться между классами.

Мой ответ находится почти в той же строке, что и @janki, но я хотел бы немного изменить фрагмент кода, как показано ниже:

if (wsObject.getFoo() != null && wsObject.getFoo().getBar() != null && wsObject.getFoo().getBar().getBaz() != null) 
   return wsObject.getFoo().getBar().getBaz().getInt();
else
   return something or throw exception;

Вы также можете добавить нулевую проверку wsObject, если есть вероятность, что этот объект будет нулевым.

Вы говорите, что некоторые методы «могут возвращаться null», но не говорите, при каких обстоятельствах они возвращаются null. Вы говорите, что ловите это, NullPointerExceptionно не говорите, почему вы это ловите. Этот недостаток информации предполагает, что вы не имеете четкого представления о том, для чего нужны исключения и почему они лучше альтернативы.

Рассмотрим метод класса, который предназначен для выполнения действия, но метод не может гарантировать, что он выполнит действие, из-за обстоятельств, не зависящих от него (что на самом деле имеет место для всех методов в Java ). Мы вызываем этот метод, и он возвращается. Код, вызывающий этот метод, должен знать, был ли он успешным. Откуда это знать? Как его можно структурировать, чтобы справиться с двумя возможностями - успехом или неудачей?

Используя исключения, мы можем написать методы, которые будут успешными как условие публикации . Если метод возвращается, он был успешным. Если он вызывает исключение, значит, он потерпел неудачу. Это большая победа для ясности. Мы можем написать код, который четко обрабатывает нормальный, успешный случай, и переместить весь код обработки ошибок в catchразделы. Часто выясняется, что подробности того, как и почему метод оказался неудачным, не важны для вызывающего, поэтому одно и то же catchпредложение можно использовать для обработки нескольких типов сбоев. И часто бывает , что метод не требует исключения улова на всех , но может просто позволить им распространяться на его вызывающий. Исключения из-за программных ошибок относятся к этому последнему классу; немногие методы могут адекватно реагировать на ошибку.

Итак, те методы, которые возвращаются null.

• nullУказывает ли значение на ошибку в вашем коде? Если это так, вы вообще не должны перехватывать исключение. И ваш код не должен пытаться переубедить самого себя. Просто напишите то, что ясно и кратко, исходя из предположения, что это сработает. Является ли цепочка вызовов методов ясной и краткой? Тогда просто используйте их.
• nullУказывает ли значение на недопустимый ввод в вашу программу? Если это так, то NullPointerExceptionисключение не следует генерировать, потому что обычно оно зарезервировано для индикации ошибок. Вероятно, вы захотите сгенерировать настраиваемое исключение, производное от IllegalArgumentException(если вы хотите исключениеIOException без проверки ) или (если вам нужно проверенное исключение). Требуется ли ваша программа для предоставления подробных сообщений об ошибках синтаксиса при недопустимом вводе? Если это так, nullто единственное, что вы можете сделать , - это проверка каждого метода на возвращаемое значение и выдача соответствующего диагностического исключения. Если вашей программе не требуется предоставлять подробную диагностику, объединение вызовов методов в цепочку, перехват любого NullPointerExceptionи последующее генерирование пользовательского исключения является наиболее ясным и кратким.

Один из ответов утверждает, что связанные вызовы методов нарушают закон Деметры и, следовательно, являются плохими. Это утверждение ошибочно.

• Когда дело доходит до разработки программ, на самом деле нет никаких абсолютных правил о том, что хорошо, а что плохо. Есть только эвристика: правила, которые верны в большинстве (даже почти во всех) случаях. Часть навыков программирования - знать, когда можно нарушать такие правила. Таким образом, краткое утверждение, что «это противоречит правилу X », на самом деле не является ответом. Это одна из ситуаций, когда правила следует нарушать?
• Закон Деметры действительно правило о API или дизайн интерфейса класса. При разработке классов полезно иметь иерархию абстракций., У вас есть классы низкого уровня, которые используют языковые примитивы для непосредственного выполнения операций и представляют объекты в абстракции, которая находится на более высоком уровне, чем языковые примитивы. У вас есть классы среднего уровня, которые делегируют классам низкого уровня и реализуют операции и представления на более высоком уровне, чем классы низкого уровня. У вас есть классы высокого уровня, которые делегируют классам среднего уровня и реализуют операции и абстракции еще более высокого уровня. (Я говорил здесь только о трех уровнях абстракции, но возможны и другие). Это позволяет вашему коду выражать себя в терминах соответствующих абстракций на каждом уровне, тем самым скрывая сложность. Обоснование Закона Деметрызаключается в том, что если у вас есть цепочка вызовов методов, это предполагает, что у вас есть класс высокого уровня, достигающий через класс среднего уровня, чтобы иметь дело непосредственно с деталями низкого уровня, и, следовательно, ваш класс среднего уровня не предоставил абстрактную операцию среднего уровня что нужно классу высокого уровня. Но похоже, что здесь ситуация не та: вы не проектировали классы в цепочке вызовов методов, они являются результатом некоторого автоматически сгенерированного кода сериализации XML (верно?), А цепочка вызовов не является нисходящей. через иерархию абстракции, потому что десериализованный XML находится на одном уровне иерархии абстракции (верно?)?

Чтобы улучшить читаемость, вы можете использовать несколько переменных, например

Foo theFoo;
Bar theBar;
Baz theBaz;

theFoo = wsObject.getFoo();

if ( theFoo == null ) {
  // Exit.
}

theBar = theFoo.getBar();

if ( theBar == null ) {
  // Exit.
}

theBaz = theBar.getBaz();

if ( theBaz == null ) {
  // Exit.
}

return theBaz.getInt();

Не лови NullPointerException. Вы не знаете, откуда он исходит (я знаю, что это маловероятно в вашем случае, но, возможно, что-то еще выбросило его), и это медленно. Вы хотите получить доступ к указанному полю, и для этого все остальные поля не должны быть пустыми. Это прекрасная веская причина проверить каждое поле. Я бы, наверное, проверил это в одном if, а затем создал бы метод для удобочитаемости. Как отмечали другие, уже возвращение -1 - это очень старая школа, но я не знаю, есть ли у вас для этого причина или нет (например, разговаривать с другой системой).

public int callService() {
    ...
    if(isValid(wsObject)){
        return wsObject.getFoo().getBar().getBaz().getInt();
    }
    return -1;
}


public boolean isValid(WsObject wsObject) {
    if(wsObject.getFoo() != null &&
        wsObject.getFoo().getBar() != null &&
        wsObject.getFoo().getBar().getBaz() != null) {
        return true;
    }
    return false;
}

Edit: Это спорно , если это disobeyes Закона Деметры , поскольку WsObject вероятно только структура данных (проверка https://stackoverflow.com/a/26021695/1528880 ).

Если вы не хотите реорганизовывать код и можете использовать Java 8, можно использовать ссылки на методы.

Сначала простая демонстрация (извините за статические внутренние классы)

public class JavaApplication14 
{
    static class Baz
    {
        private final int _int;
        public Baz(int value){ _int = value; }
        public int getInt(){ return _int; }
    }
    static class Bar
    {
        private final Baz _baz;
        public Bar(Baz baz){ _baz = baz; }
        public Baz getBar(){ return _baz; }   
    }
    static class Foo
    {
        private final Bar _bar;
        public Foo(Bar bar){ _bar = bar; }
        public Bar getBar(){ return _bar; }   
    }
    static class WSObject
    {
        private final Foo _foo;
        public WSObject(Foo foo){ _foo = foo; }
        public Foo getFoo(){ return _foo; }
    }
    interface Getter<T, R>
    {
        R get(T value);
    }

    static class GetterResult<R>
    {
        public R result;
        public int lastIndex;
    }

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) 
    {
        WSObject wsObject = new WSObject(new Foo(new Bar(new Baz(241))));
        WSObject wsObjectNull = new WSObject(new Foo(null));

        GetterResult<Integer> intResult
                = getterChain(wsObject, WSObject::getFoo, Foo::getBar, Bar::getBar, Baz::getInt);

        GetterResult<Integer> intResult2
                = getterChain(wsObjectNull, WSObject::getFoo, Foo::getBar, Bar::getBar, Baz::getInt);


        System.out.println(intResult.result);
        System.out.println(intResult.lastIndex);

        System.out.println();
        System.out.println(intResult2.result);
        System.out.println(intResult2.lastIndex);

        // TODO code application logic here
    }

    public static <R, V1, V2, V3, V4> GetterResult<R>
            getterChain(V1 value, Getter<V1, V2> g1, Getter<V2, V3> g2, Getter<V3, V4> g3, Getter<V4, R> g4)
            {
                GetterResult result = new GetterResult<>();

                Object tmp = value;


                if (tmp == null)
                    return result;
                tmp = g1.get((V1)tmp);
                result.lastIndex++;


                if (tmp == null)
                    return result;
                tmp = g2.get((V2)tmp);
                result.lastIndex++;

                if (tmp == null)
                    return result;
                tmp = g3.get((V3)tmp);
                result.lastIndex++;

                if (tmp == null)
                    return result;
                tmp = g4.get((V4)tmp);
                result.lastIndex++;


                result.result = (R)tmp;

                return result;
            }
}

Вывод

241
4

null
2

Интерфейс Getter- это просто функциональный интерфейс, вы можете использовать любой эквивалент.
GetterResultclass, аксессоры опущены для ясности, содержат результат цепочки геттеров, если таковые имеются, или индекс последнего вызванного геттера.

Метод getterChainпредставляет собой простой шаблонный фрагмент кода, который может быть сгенерирован автоматически (или вручную при необходимости).
Я структурировал код так, чтобы повторяющийся блок был очевиден.

Это не идеальное решение, поскольку вам все равно нужно определять одну перегрузку для getterChainкаждого количества геттеров.

Вместо этого я бы реорганизовал код, но если не получается, и вы часто обнаруживаете, что используете длинные цепочки геттеров, вы можете подумать о создании класса с перегрузками, которые занимают от 2 до, скажем, 10 геттеров.

Как уже говорили другие, соблюдение Закона Деметры, безусловно, является частью решения. Другая часть, где это возможно, - изменить эти связанные методы, чтобы они не могли вернуться null. Вы можете избежать возврата null, вместо этого возвращая пустой String, пустой Collectionили какой-либо другой фиктивный объект, который означает или делает то, что вызывающий будет делать null.

Я хотел бы добавить ответ, в котором основное внимание уделяется значению ошибки . Нулевое исключение само по себе не дает никакого смысла полной ошибки. Поэтому я бы посоветовал не иметь с ними дела напрямую.

Есть тысячи случаев, когда ваш код может пойти не так: не удается подключиться к базе данных, исключение ввода-вывода, ошибка сети ... Если вы разбираетесь с ними один за другим (например, с нулевой проверкой здесь), это было бы слишком хлопотно.

В коде:

wsObject.getFoo().getBar().getBaz().getInt();

Даже если вы знаете, какое поле имеет значение NULL, вы не знаете, что пошло не так. Может быть, Bar равен нулю, но ожидается ли это? Или это ошибка данных? Подумайте о людях, которые читают ваш код

Как и в ответе xenteros, я бы предложил использовать настраиваемое исключение без проверки . Например, в этой ситуации: Foo может быть нулевым (допустимые данные), но Bar и Baz никогда не должны быть нулевыми (недопустимые данные)

Код можно переписать:

void myFunction()
{
    try 
    {
        if (wsObject.getFoo() == null)
        {
          throw new FooNotExistException();
        }

        return wsObject.getFoo().getBar().getBaz().getInt();
    }
    catch (Exception ex)
    {
        log.error(ex.Message, ex); // Write log to track whatever exception happening
        throw new OperationFailedException("The requested operation failed")
    }
}


void Main()
{
    try
    {
        myFunction();
    }
    catch(FooNotExistException)
    {
        // Show error: "Your foo does not exist, please check"
    }
    catch(OperationFailedException)
    {
        // Show error: "Operation failed, please contact our support"
    }
}

NullPointerException является исключением во время выполнения, поэтому, вообще говоря, не рекомендуется его ловить, но следует избегать его.

Вам нужно будет перехватить исключение везде, где вы хотите вызвать метод (или оно будет распространяться вверх по стеку). Тем не менее, если в вашем случае вы можете продолжать работать с этим результатом со значением -1, и вы уверены, что он не будет распространяться, потому что вы не используете какие-либо «части», которые могут быть нулевыми, то мне кажется правильным Лови

Редактировать:

Я согласен с более поздним ответом от @xenteros, лучше будет запустить собственное исключение, вместо того, чтобы возвращать -1, вы можете его назвать, InvalidXMLExceptionнапример.

Подписываюсь на этот пост со вчерашнего дня.

Я комментировал / голосовал за комментарии, в которых говорится, что ловить NPE - это плохо. Вот почему я это делаю.

package com.todelete;

public class Test {
    public static void main(String[] args) {
        Address address = new Address();
        address.setSomeCrap(null);
        Person person = new Person();
        person.setAddress(address);
        long startTime = System.currentTimeMillis();
        for (int i = 0; i < 1000000; i++) {
            try {
                System.out.println(person.getAddress().getSomeCrap().getCrap());
            } catch (NullPointerException npe) {

            }
        }
        long endTime = System.currentTimeMillis();
        System.out.println((endTime - startTime) / 1000F);
        long startTime1 = System.currentTimeMillis();
        for (int i = 0; i < 1000000; i++) {
            if (person != null) {
                Address address1 = person.getAddress();
                if (address1 != null) {
                    SomeCrap someCrap2 = address1.getSomeCrap();
                    if (someCrap2 != null) {
                        System.out.println(someCrap2.getCrap());
                    }
                }
            }
        }
        long endTime1 = System.currentTimeMillis();
        System.out.println((endTime1 - startTime1) / 1000F);
    }
}

  public class Person {
    private Address address;

    public Address getAddress() {
        return address;
    }

    public void setAddress(Address address) {
        this.address = address;
    }
}

package com.todelete;

public class Address {
    private SomeCrap someCrap;

    public SomeCrap getSomeCrap() {
        return someCrap;
    }

    public void setSomeCrap(SomeCrap someCrap) {
        this.someCrap = someCrap;
    }
}

package com.todelete;

public class SomeCrap {
    private String crap;

    public String getCrap() {
        return crap;
    }

    public void setCrap(String crap) {
        this.crap = crap;
    }
}

Вывод

3,216

0,002

Я вижу здесь явного победителя. Наличие проверок if намного дешевле, чем перехват исключения. Я видел, как это делается в Java-8. Учитывая, что 70% текущих приложений все еще работают на Java-7, я добавляю этот ответ.

Практический результат Для любых критически важных приложений обработка NPE стоит дорого.

Если эффективность является проблемой, следует рассмотреть вариант «улова». Если 'catch' нельзя использовать, потому что он будет распространяться (как указано в 'SCouto'), тогда используйте локальные переменные, чтобы избежать множественных вызовов методов getFoo(), getBar()и getBaz().

Стоит подумать о создании собственного исключения. Назовем это MyOperationFailedException. Вы можете выбросить его вместо того, чтобы вернуть значение. Результат будет таким же - вы выйдете из функции, но не вернете жестко запрограммированное значение -1, которое является антипаттерном Java. В Java мы используем исключения.

try {
    return wsObject.getFoo().getBar().getBaz().getInt();
} catch (NullPointerException ignored) {
    throw new MyOperationFailedException();
}

РЕДАКТИРОВАТЬ:

По результатам обсуждения в комментариях позвольте мне добавить кое-что к своим предыдущим мыслям. В этом коде есть две возможности. Во-первых, вы принимаете значение null, а во-вторых, что это ошибка.

Если это ошибка, и она возникает, вы можете отладить свой код, используя другие структуры для целей отладки, когда точек останова недостаточно.

Если это приемлемо, вам все равно, где появился этот нуль. Если вы это сделаете, вам определенно не следует связывать эти запросы.

У вас есть длинный, но очень читаемый метод. Если бы я был новым разработчиком, пришедшим к вашей кодовой базе, я мог бы довольно быстро увидеть, что вы делаете. Большинство других ответов (включая перехват исключения), похоже, не делают вещи более читаемыми, а некоторые, на мой взгляд, делают их менее читаемыми.

Учитывая, что вы, вероятно, не контролируете сгенерированный источник, и предполагая, что вам действительно нужно получить доступ к нескольким глубоко вложенным полям здесь и там, я бы рекомендовал обернуть каждый глубоко вложенный доступ методом.

private int getFooBarBazInt() {
    if (wsObject.getFoo() == null) return -1;
    if (wsObject.getFoo().getBar() == null) return -1;
    if (wsObject.getFoo().getBar().getBaz() == null) return -1;
    return wsObject.getFoo().getBar().getBaz().getInt();
}

Если вы обнаружите, что пишете много этих методов или если у вас возникнет соблазн сделать эти общедоступные статические методы, я бы создал отдельную объектную модель, вложенную, как вы хотите, только с теми полями, которые вам нужны, и преобразовал бы из Интернета объектную модель services в вашу объектную модель.

Когда вы общаетесь с удаленной веб-службой, очень типично иметь «удаленный домен» и «домен приложения» и переключаться между ними. Удаленный домен часто ограничен веб-протоколом (например, вы не можете отправлять вспомогательные методы туда и обратно в чистой службе RESTful, а глубоко вложенные объектные модели являются обычным явлением, чтобы избежать множественных вызовов API) и поэтому не идеальны для прямого использования в ваш клиент.

Например:

public static class MyFoo {

    private int barBazInt;

    public MyFoo(Foo foo) {
        this.barBazInt = parseBarBazInt();
    }

    public int getBarBazInt() {
        return barBazInt;
    }

    private int parseFooBarBazInt(Foo foo) {
        if (foo() == null) return -1;
        if (foo().getBar() == null) return -1;
        if (foo().getBar().getBaz() == null) return -1;
        return foo().getBar().getBaz().getInt();
    }

}

return wsObject.getFooBarBazInt();

применяя Закон Деметры,

class WsObject
{
    FooObject foo;
    ..
    Integer getFooBarBazInt()
    {
        if(foo != null) return foo.getBarBazInt();
        else return null;
    }
}

class FooObject
{
    BarObject bar;
    ..
    Integer getBarBazInt()
    {
        if(bar != null) return bar.getBazInt();
        else return null;
    }
}

class BarObject
{
    BazObject baz;
    ..
    Integer getBazInt()
    {
        if(baz != null) return baz.getInt();
        else return null;
    }
}

class BazObject
{
    Integer myInt;
    ..
    Integer getInt()
    {
        return myInt;
    }
}

Давать ответ, который кажется отличным от всех остальных.

Я рекомендую вам проверить NULLв ifс.

Причина:

Мы не должны оставлять ни единого шанса, что наша программа выйдет из строя. NullPointer генерируется системой. Поведение исключений, созданных Системой, невозможно предсказать . Не следует оставлять свою программу в руках Системы, если у вас уже есть способ справиться с ней самостоятельно. И поместите механизм обработки исключений для дополнительной безопасности. !!

Чтобы упростить чтение кода, попробуйте это для проверки условий:

if (wsObject.getFoo() == null || wsObject.getFoo().getBar() == null || wsObject.getFoo().getBar().getBaz() == null) 
   return -1;
else 
   return wsObject.getFoo().getBar().getBaz().getInt();

РЕДАКТИРОВАТЬ :

Здесь вам нужно сохранить эти значения wsObject.getFoo(), wsObject.getFoo().getBar(), wsObject.getFoo().getBar().getBaz()в некоторых переменных. Я не делаю этого, потому что не знаю возвращаемые типы этих функций.

Любые предложения будут оценены .. !!

Я написал класс, Snagкоторый позволяет вам определять путь для навигации по дереву объектов. Вот пример его использования:

Snag<Car, String> ENGINE_NAME = Snag.createForAndReturn(Car.class, String.class).toGet("engine.name").andReturnNullIfMissing();

Это означает, что экземпляр ENGINE_NAMEбудет эффективно вызывать Car?.getEngine()?.getName()переданный ему экземпляр и возвращать его, nullесли возвращается какая-либо ссылка null:

final String name =  ENGINE_NAME.get(firstCar);

Он не опубликован на Maven, но если кому-то это пригодится, он здесь (конечно, без гарантии!)

Это немного простовато, но, похоже, работает. Очевидно, что он более устарел с более поздними версиями Java и других языков JVM, которые поддерживают безопасную навигацию или Optional.