Java for-each цикл throw NullPointException

Следующий сегмент java приведет к исключению NullPointException, поскольку список переменных имеет значение NULL, которое передается в цикл for-each.

List<> arr = null;
for (Object o : arr) {
    System.out.println("ln "+o);
}

Я думаю, что for (Object o : arr){ } эквивалентно

for (int i = 0; i < arr.length; i++) { }

и/или

for (Iterator<type> iter = arr.iterator(); iter.hasNext(); ){ 
   type var = iter.next(); 
}

В обоих случаях arr имеет значение null, вызывает arr.length или arr.iterator() выдает исключение NullPointException

Мне просто интересно, почему for (Object o : arr){ } НЕ переводится на

if (arr!=null){
  for (int i = 0; i < arr.length; i++) { 
  }
}
and
if (arr!=null){
    for (Iterator<type> iter = arr.iterator(); iter.hasNext(); ){ 
       type var = iter.next(); 
    }
}

Включить выражение arr!= null может уменьшить вложенность кода.

ОТВЕТЫ

Ответ 1

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

  • Как вы показали, текущее поведение цикла for (:) - очень легко понять. Другое поведение не

  • Это было бы единственное, что было бы в Java-сообществе таким образом.

  • Это не будет эквивалентно простому циклу for, поэтому миграция между ними фактически не будет эквивалентной.

  • Использование null - это плохая привычка, так что NPE - отличный способ сообщить разработчику, что "вы F *** разобрались, очистите свой беспорядок" с предлагаемым поведением, проблема будет просто скрыта.

  • Что делать, если вы хотите сделать что-либо еще с массивом до или после цикла... теперь у вас будет двойная проверка в коде.

Ответ 2

Чтобы ответить на ваш первый вопрос: нет, эти три цикла не эквивалентны. Во-вторых, в этих циклах нет нулевой проверки; нет смысла пытаться перебирать то, что не существует.

Предположим, что мы имеем следующий класс:

import java.util.Arrays;
import java.util.Iterator;
import java.util.List;

public class EnhancedFor {


    private List<Integer> dummyList = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);
    private List<Integer> nullList = null;

    public void enhancedForDummyList() {
        for(Integer i : dummyList) {
            System.out.println(i);
        }
    }

    public void iteratorDummyList() {
        for(Iterator<Integer> iterator = dummyList.iterator(); iterator.hasNext();) {
            System.out.println(iterator.next());
        }
    }

    public void normalLoopDummyList() {
        for(int i = 0; i < dummyList.size(); i++) {
            System.out.println(dummyList.get(i));
        }
    }
}

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

1: Enhanced For vter Iterator

Здесь байт-код для расширенного цикла.

public enhancedForDummyList()V
   L0
    LINENUMBER 12 L0
    ALOAD 0
    GETFIELD EnhancedFor.dummyList : Ljava/util/List;
    INVOKEINTERFACE java/util/List.iterator ()Ljava/util/Iterator;
    ASTORE 1
   L1
   FRAME APPEND [java/util/Iterator]
    ALOAD 1
    INVOKEINTERFACE java/util/Iterator.hasNext ()Z
    IFEQ L2
    ALOAD 1
    INVOKEINTERFACE java/util/Iterator.next ()Ljava/lang/Object;
    CHECKCAST java/lang/Integer
    ASTORE 2
   L3
    LINENUMBER 13 L3
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    ALOAD 2
    INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/Object;)V
   L4
    LINENUMBER 14 L4
    GOTO L1
   L2
    LINENUMBER 15 L2
   FRAME CHOP 1
    RETURN
   L5
    LOCALVARIABLE i Ljava/lang/Integer; L3 L4 2
    LOCALVARIABLE i$ Ljava/util/Iterator; L1 L2 1
    LOCALVARIABLE this LEnhancedFor; L0 L5 0
    MAXSTACK = 2
    MAXLOCALS = 3

Ниже приведен байт-код для итератора.

public iteratorDummyList()V
   L0
    LINENUMBER 24 L0
    ALOAD 0
    GETFIELD EnhancedFor.dummyList : Ljava/util/List;
    INVOKEINTERFACE java/util/List.iterator ()Ljava/util/Iterator;
    ASTORE 1
   L1
   FRAME APPEND [java/util/Iterator]
    ALOAD 1
    INVOKEINTERFACE java/util/Iterator.hasNext ()Z
    IFEQ L2
   L3
    LINENUMBER 25 L3
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    ALOAD 1
    INVOKEINTERFACE java/util/Iterator.next ()Ljava/lang/Object;
    INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/Object;)V
    GOTO L1
   L2
    LINENUMBER 27 L2
   FRAME CHOP 1
    RETURN
   L4
    LOCALVARIABLE iterator Ljava/util/Iterator; L1 L2 1
    // signature Ljava/util/Iterator<Ljava/lang/Integer;>;
    // declaration: java.util.Iterator<java.lang.Integer>
    LOCALVARIABLE this LEnhancedFor; L0 L4 0
    MAXSTACK = 2
    MAXLOCALS = 2

В конце концов, похоже, что они делают очень похожие вещи. Они используют один и тот же интерфейс. Существует вариация в том, что усиленный цикл for использует две переменные для текущего значения (i) и курсор для остальной части списка (i$), тогда как итератору требуется только курсор для вызова .next().

Аналогичный, но не совсем то же.

2. Enhanced For vs. for-Loop

Добавьте в байт-код для цикла for.

public normalLoopDummyList()V
   L0
    LINENUMBER 24 L0
    ICONST_0
    ISTORE 1
   L1
   FRAME APPEND [I]
    ILOAD 1
    ALOAD 0
    GETFIELD EnhancedFor.dummyList : Ljava/util/List;
    INVOKEINTERFACE java/util/List.size ()I
    IF_ICMPGE L2
   L3
    LINENUMBER 25 L3
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    ALOAD 0
    GETFIELD EnhancedFor.dummyList : Ljava/util/List;
    ILOAD 1
    INVOKEINTERFACE java/util/List.get (I)Ljava/lang/Object;
    INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/Object;)V
   L4
    LINENUMBER 24 L4
    IINC 1 1
    GOTO L1
   L2
    LINENUMBER 27 L2
   FRAME CHOP 1
    RETURN
   L5
    LOCALVARIABLE i I L1 L2 1
    LOCALVARIABLE this LEnhancedFor; L0 L5 0
    MAXSTACK = 3
    MAXLOCALS = 2

Он делает что-то другое. Он не использует интерфейс Iterator вообще.. Вместо этого мы вызываем вызов get(), который указан только List, а не Iterator.

3. Вывод

Существует веская причина, почему список разыменования, который мы разыменовываем, принимается не null - мы вызываем методы, указанные интерфейсом. Если бы эти методы не были реализованы, это было бы иначе: throw a UnsupportedOperationException. Если объект, который мы пытаемся вызвать на контракт, не существует - это просто не имеет смысла.

Ответ 3

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

public static boolean canLoopList(List<?> list) {
    if (list != null && !list.isEmpty()) {
        return true;
    }
    return false;
}

то перед циклом любого списка проверьте список:

if (canLoopList(yourList)) {
    for(Type var : yourList) {
    ...
}
}

Ответ 4

Причина, по которой она не вставляет нулевую проверку, связана с тем, что она не определена. Вы можете найти правила для циклов foreach в разделе 14.14.2 Спецификации языка Java.

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

  • Это естественно. цикл foreach ведет себя как эквивалент цикла без магического поведения

  • Желательно. Обычно люди не хотят, чтобы код терпел неудачу, когда возникает ошибка.

Проблема эффективности, предложенная Элвином Вонгом, скорее всего, была незначительной. JVM обычно оптимизирует нулевые проверки в случаях, когда переменная всегда не равна нулю, поэтому влияние производительности незначительно.

Ответ 5

Если у меня есть нулевой массив ArrayList, то сколько объектов оно содержит? Мой ответ равен нулю. Поэтому, по моему мнению, усиленный цикл не должен бросать NPE для

List<Object> myList = null;
for (Object obj : myList) {
    System.out.println(obj.toString());
}

но это так. Очевидно, теперь это не изменится в спецификации java, поэтому, возможно, они должны ввести elvis и безопасных навигационных операторов, так что это поддерживается:

List<Object> myList = null;
for (Object obj ?: myList) {
    System.out.println(obj?.toString());
}

Тогда у разработчиков есть выбор, хотите ли они, чтобы NPE был брошен или мог обрабатывать нулевые коллекции изящно.

Ответ 6

"Я думаю, что для (Object o: arr) {} эквивалентно

for (int я = 0; я < arr.length; я ++) {} "

Почему ты так думаешь? как может arr.length не выдавать исключение, если arr null? null не может иметь длину.

Если for(Object o :arr) не генерирует исключение, это должно означать, что цикл for (:) достаточно умен, чтобы проверить, является ли arr нулевым, а не пытаться вытащить элементы из него. Очевидно, что цикл for (;;) не такой умный.

Ответ 7

Часто не рекомендуется избегать исключений с нулевым указателем с помощью атрибутов if(o != null) - это может вообще не иметь смысла для o равным нулю, и в этом случае вы хотите бросить и зарегистрировать исключение, если это окажется в этом случае.

Ответ 8

Вы уже ответили на свой вопрос, если arr равно null. arr.lenght выбрасывает NullPointerException. Поэтому for (Object o : arr){ } эквивалентно

for (int i = 0; i < arr.length; i++) { }