Нульова перевірка ланцюга проти лову 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 .

Чи відсутність помилки чи помилка?

Але також подумайте, чи це дійсний результат для проміжних методів повернення нуля чи це ознака помилки. Якщо це завжди помилка, то, ймовірно, краще кинути виняток, ніж повертати спеціальне значення, або для самих проміжних методів кидати виняток.

Можливо, додаткові опції?

Якщо, з іншого боку, відсутні значення значень проміжних методів дійсні, можливо, ви можете перейти до Optional s для них?

Тоді ви можете використовувати їх так:

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

Чому б не обов’язково?

Єдина причина, яку я можу подумати за те, що я не використовую, Optionalце те, що це справді критична частина коду, і якщо накладні витрати на збирання сміття виявляються проблемою. Це відбувається тому, що при Optionalкожному виконанні коду виділяється декілька об'єктів, і VM, можливо, не зможе їх оптимізувати. У такому випадку ваш оригінальний тест 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 розробила механізм винятків, щоб уникнути цього старомодного способу, який походить з мови С.

Кидання NullPointerException- теж не найкращий варіант. Ви можете надати свій власний виняток (зробивши його перевіреним, щоб гарантувати, що користувачем буде керувати ним чи невірно обробляти його простішим способом), або використовувати певний виняток із аналізатора XML, який ви використовуєте.

Якщо припустити, що структура класу насправді виходить з-під нашого контролю, як це здається, я вважаю, що прийняття NPE, як було запропоновано у питанні, справді є розумним рішенням, якщо продуктивність не викликає особливих проблем. Одне невелике поліпшення може полягати в обробці логіки кидка / лову, щоб уникнути захаращення:

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вказує значення недійсне введення у вашу програму? Якщо це так, a 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. Ви не знаєте, звідки воно походить (я знаю, що це не вірно у вашому випадку, але, можливо, щось інше кинуло), і це повільно. Ви хочете отримати доступ до вказаного поля, і для цього будь-яке інше поле повинно бути недійсним. Це ідеальна вагома причина для перевірки кожного поля. Я, мабуть, перевірив би це за один раз, якщо потім створити метод для читабельності. Як зазначали інші, повернення -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;
}

Редагувати: Суперечливо, якщо він не дотримується Закону Деметера, оскільки 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

нульовий
2

Інтерфейс Getter- це лише функціональний інтерфейс, ви можете використовувати будь-який еквівалент.
GetterResultклас, аксесуари, позбавлені ясності, містять результат ланцюга геттера, якщо такий є, або індекс останнього викликаного геттера.

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

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

Я б замість цього перефактурував код, але якщо ви не можете, і ви знайдете себе, використовуючи довгі ланцюги геттера, ви можете розглянути можливість створення класу з перевантаженнями, що займають від 2 до, скажімо, 10, геттерів.

Як говорили інші, повага до Закону про Деметер, безумовно, є частиною рішення. Інша частина, де це можливо, полягає в зміні цих прикованих методів, щоб вони не могли повернутися null. Ви можете уникнути повернення null, замість того, щоб повернути порожній String, порожній Collectionчи якийсь інший фіктивний об'єкт, який означає або робить все, що зробив би абонент null.

Я хотів би додати відповідь, яка зосереджується на значенні помилки . Нульовий виняток сам по собі не забезпечує повної помилки сенсу. Тому я б радив уникати прямого спілкування з ними.

Є тисячі випадків, коли ваш код може піти не так: не можна підключитися до бази даних, виключення IO, помилка в мережі ... Якщо ви попрацюєте з ними по черзі (як, наприклад, нульова перевірка тут), це було б занадто великим клопотом.

У коді:

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

Навіть коли ви знаєте, яке поле недійсне, ви не маєте уявлення про те, що йде не так. Можливо, Бар недійсний, але чи очікується це? Або це помилка даних? Подумайте про людей, які читають ваш код

Як і у відповіді 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

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

Підсумкові дані Для будь-яких найважливіших застосувань, необхідних для роботи з NPE, це дорого.

Якщо ефективність є проблемою, тоді слід розглянути варіант "лову". Якщо «зловити» не може бути використаний , так як він буде поширюватися (як уже згадувалося «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();
}

Якщо ви виявите, що ви пишете багато цих методів або якщо у вас виникає спокуса зробити ці загальнодоступні статичні методи, то я створив би окрему об’єктну модель, вкладену як вам хотілося, лише поля, які вам цікаві, та конвертувати з Інтернету. сервісна модель об'єкта до вашої об'єктної моделі.

Під час спілкування з віддаленою веб-службою дуже типово мати "віддалений домен" і "домен програми" та перемикатися між ними. Віддалений домен часто обмежений веб-протоколом (наприклад, ви не можете надсилати допоміжні методи туди-сюди за допомогою чистого сервісу 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в ifs.

Причина:

Ми не повинні залишати єдиного шансу, коли наша програма буде розбита. 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.