Как будто вы пытаетесь получить доступ к объекту, который является null
. Рассмотрим ниже пример:
TypeA objA;
. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException
, что имеет смысл.
См. Также этот пример:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
Я согласен с цитатой Роберта Мартина в «Чистом коде» ( цитировано выше ): чем меньше параметров, тем лучше. Сложно понять более 5-7 параметров и вызовов методов. Ситуация становится особенно плохой, если некоторые параметры являются необязательными (и поэтому принимают нулевые значения) или если все параметры имеют один и тот же тип (что еще больше затрудняет определение того, какой параметр является каким). Если вы можете объединить параметры в связанные объекты домена, такие как Customer и Account, с вашим кодом будет гораздо приятнее работать.
Существует крайний случай: если у вас есть вызов метода, который принимает переменное количество параметров которые образуют логический набор , меньше когнитивных накладных расходов при большем количестве параметров. Например, вам может понадобиться метод, определяющий количество повторных попыток HTTP-запроса, выраженное в миллисекундах между повторными попытками. Три попытки с интервалом в 1, 2 и 3 секунды могут быть указаны как:
retries(1000, 2000, 3000)
В этом ограниченном случае добавление дополнительных параметров к вызову не сильно увеличивает умственную перегрузку.
Еще одно соображение - поддерживает ли ваш язык named списки параметров и позволяют опускать необязательные параметры.