Лучшая практика в отношении NPE и нескольких выражений в одной строке

Question

Мне интересно, является ли это общепринятой практикой или нет, чтобы избежать нескольких вызовов на одной линии в отношении возможных NPE, и если да, то при каких обстоятельствах. Например:

anObj.doThatWith(myObj.getThis());

против

Object o = myObj.getThis();
anObj.doThatWith(o);

Последний более многословен, но если есть NPE, вы сразу знаете, что такое null. Однако, это также требует создания имени для переменной и дополнительных операторов импорта.

Итак, мои вопросы по этому поводу:

• Эта проблема что-то стоит проектирование вокруг? Лучше пойти для первой или второй возможности?
• Может ли создание имени переменной повлиять на производительность?
• Есть ли предложение изменить исключение сообщение, чтобы иметь возможность определить, что объект null в будущих версиях Java?

Answer 1

Стоит ли придумывать эту проблему? Лучше пойти по первой или второй возможности?

ИМО, нет. Выберите версию кода, которая наиболее читаема .

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

Является ли создание имени переменной чем-то, что повлияет на производительность?

Добавление дополнительной переменной может увеличить размер кадра стека или увеличить время, в течение которого некоторые объекты остаются достижимыми. Но оба эффекта вряд ли будут значительными.

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

Не то, чтобы я знал. Реализация такой функции, вероятно, будет иметь существенные недостатки производительности.

Answer 2

Если вы уверены, что getThis() не может вернуть значение null, первый вариант в порядке. Вы можете использовать аннотации контракта в своем коде для проверки таких условий. Например, Parasoft JTest использует аннотацию типа @post $result != null и отмечает все методы без аннотации, которые используют возвращаемое значение без проверки.

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

Object o = getThis();

if (null == o) {
    log.error("mymethod: Could not retrieve this");
} else {
    o.doThat();
}

Answer 3

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

Answer 4

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

Answer 5

Лично мне не нравится однострочный код «шаблона проектирования», поэтому я поддерживаю всех, кто говорит, чтобы ваш код читался. Хотя я видел гораздо худшие строки кода в существующих проектах, подобных этому:

someMap.put(
     someObject.getSomeThing().getSomeOtherThing().getKey(),
     someObject.getSomeThing().getSomeOtherThing()) 

Я думаю, что никто не станет утверждать, что это не способ написания поддерживаемого кода.

Что касается использования аннотаций - к сожалению, не все разработчики используют одну и ту же среду IDE, и пользователи Eclipse не выиграют от @ Nullable и @ NotNull аннотации. А без интеграции с IDE они не имеют большого преимущества (кроме некоторой дополнительной документации). Однако я рекомендую способность assert . Хотя это помогает только во время выполнения, оно помогает найти большинство причин NPE и не влияет на производительность, а также делает предположения, которые ваш код делает более понятными.